classification
Title: distutils dereferences symlinks on Mac OS X but not on Linux
Type: behavior Stage:
Components: Distutils Versions: Python 2.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: eric.araujo Nosy List: Arfrever, eric.araujo, eric.smith, olliewalsh, tarek
Priority: normal Keywords:

Created on 2012-06-27 12:53 by olliewalsh, last changed 2012-07-04 11:07 by olliewalsh.

Messages (5)
msg164149 - (view) Author: Ollie Walsh (olliewalsh) Date: 2012-06-27 12:53
Hi,

This is related to #12585.

Distutils sdist builds a package tree using hardlinks to the source if supported by the OS. This is then tarred/zipped/etc...

If the source contains symbolic links to external files:

On Linux (and apparently Solaris) they are not dereferenced and the resulting package is broken.

On OSX (and apparently all BSD kernels) a hardlink to a symlink will dereference the symlink first and the resulting tgz package is ok. However I would expect issue #8876 to be more likely as the symlink could references a different filesystem which would case hardlinking to fail.


In #12585 I assume that zip dereferences the symlinks which masks the issue.

distutils2 appears to always copy instead of hardlinking resolving all of these issues.

distutils can be monkey patched to do the same: 
http://article.gmane.org/gmane.comp.python.distutils.devel/2078
msg164542 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-07-02 20:27
As I said in the other bug, symlinks handling in not fully specified: some functions (like copy_file and copy_tree) have arguments to control copy/link/symlink, but the higher-level commands don’t expose that choice to the user.  At present I am not sure if having symlinks in a distribution makes sense, and if the install command (or platform-specific systems for bdists) supports it.  I am not sure what the correct behavior would be here.

(BTW the example you link to is not at all monkey-patching, but clean extension of distutils using the provided hooks. :)
msg164544 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-07-02 20:41
(Hm OK “del os.link” is definitely a hack :)
msg164643 - (view) Author: Ollie Walsh (olliewalsh) Date: 2012-07-04 11:05
Hi,

> As I said in the other bug, symlinks handling in not fully specified

Yes. I've mostly submitted a bug report in case anybody else encounters the problem.

> At present I am not sure if having symlinks in a distribution makes sense

I agree.
In my case symlinks are being used to restructure a large legacy module into smaller packages. When creating sdists the symlinks are dereferenced on another developer's host (OSX) and all is well but they on my host (Linux) I get packages with broken symlinks.

> BTW the example you link to is not at all monkey-patching

My mistake. When I worked around this issue I did monkey-patch sdist. I also just wrapped the source path is os.path.readlink() before hardlinking. I think the approach in that link is a much better solution so I have referred to it instead.

-Ollie
msg164644 - (view) Author: Ollie Walsh (olliewalsh) Date: 2012-07-04 11:07
PS that should be os.readlink()
History
Date User Action Args
2012-07-04 11:07:24olliewalshsetmessages: + msg164644
2012-07-04 11:05:20olliewalshsetmessages: + msg164643
2012-07-02 20:41:24eric.araujosetmessages: + msg164544
2012-07-02 20:27:23eric.araujosetmessages: + msg164542
2012-06-27 15:53:46Arfreversetnosy: + Arfrever
2012-06-27 13:33:26eric.smithsetnosy: + eric.smith
2012-06-27 12:53:40olliewalshcreate