On 22 February 2003, Aki Niimura said:
Sorry to bother you. I have a question on Python Distutil and so far I couldn't find a solution in the Internet.
Please ask Distutils questions on distutils-sig@python.org. I'll try to answer, but I have not been heavily involved with the Distutils for quite a while.
My stumbling block was symbloc-link. In my project working directory, there are several files linked from another project directory (symblic link).
The distutils are mostly ignorant of symbolic links, because they're not portable to Windows or Mac OS. So whatever "tar" does by default with symlinks is the behaviour that you see.
(ex.) project_A (the project to be distributed) setup.py (foo.py, bar.py) foo.py --> project_B.foo.py bar.py
project_B (a project happened to have a useful module) foo.py
When I run 'python setup.py sdist', a <project>-<version>.tar.gz was created but the symbolic link files remained symbolic link.
Right, because tar preserves symlinks by default.
My questions are: (1) Is there any way to ask distutil to treat the file as a plain file not a link? (hopefully file by file)
No, not as far as I know. I can think of two kludges that might work: * create a ZIP file instead of a tarball -- ZIP files cannot represent symlinks, so the symlink will be followed: ./setup.py sdist --formats=zip * write a wrapper for "tar" that forces the "-h" option (which I think makes tar follow symlinks) into the real tar command line
(2) What is the right approach (to your sense) to setup a project like this?
If this is a small, personal project that only you work on, you could
make project_A/foo.py a hardlink to ../project_B/foo.py. Hardlinks are
best avoided though -- too implicit. But I don't have any other ideas
offhand.
Greg
--
Greg Ward