Lennart Regebro wrote:
On Sat, Jan 31, 2009 at 23:21, zooko <zooko@zooko.com> wrote:
Many other people, however, are unwilling to let the Python packaging tool nor the packages that it is installing write into their system directories. For these people, the system directories are never allowed to be written into by any tool other than their operating system packaging tool e.g. apt. For these people, offering a new feature so that, in addition to the Python packaging tool scribbling into their system directory at install time, it will *also* later scribble into it again attempting to undo the changes that it earlier did is only compounding the problem. :-)
For those people, there are several potential solutions. One is the path from Python package through Python packaging tool (e.g. stdeb) to operating system package (e.g. .deb) to operating system tool (e.g. apt) to system directories. Another is GNU stow.
For me, and for some hackers that I've talked to, making setuptools compatible with GNU stow would satisfy their need to have a way to cleanly uninstall.
So, please consider this a reminder in the distutils development process that you are undergoing that GNU stow compatibility has many benefits.
As far as I can figure out, that's just a matter of installing things with a prefix, like /usr/local/stow/yoursoftware instead of /usr/local and then using stow to symlink everything into /usr/local/bin and /usr/local/lib, etc. I may have misunderstood, though, but if not it should already be compatible...
There are two problems with stow and setuptools: - setuptools refuses to install in a directory not in PYTHONPATH, so python setup.py install --prefix=/usr/local/stow/my-package does not work when setup.py uses setuptools. You have to use --single-version-externally-managed (plus another option required by this one). That's the most annoying point, since it depends on whether setup.py uses setuptools or plain distutils. From a user POV, setuptools broke standard python behavior. - namespace packages: the fact that namespace/__init__ are 'owned' by several packages is a fundamental problem (not only for stow, but almost any package system). But unless python itself supports namespace packages, I don't see any solution to this one. cheers, Davod