Christian Holtje wrote:
Ian Bicking wrote:
Setuptools and people using setuptools can only deal with actual issues, not with vague dislikes. This is open source, issues get resolved, but there's never any guarantee that issues don't *exist*.
Hiya! I really like setuptools and the eggs and stuff. I want to help you out by giving you a specific user case. I don't fully understand setuptools, so I apologize in advanced for any errors.
I am a system administrator for several systems. I use a distro to manage most of my software, but obviously some python modules don't come with my distro (too new or the distro doesn't have it).
I usually solve this by doing the following as a non-root user: |$ /usr/bin/python setup.py install --prefix=/usr/local/stow/projectname-version $ cd /usr/local/stow $ stow -D projectname-oldversion # optional -- removes old version $ stow projectname-version|
This allows me to keep the previous version around in case I need to roll back.
The discussion in "A prefix option?" and "DWIM installation with setuptools" is, I think, about similar issues. Well, depending on your granularity. If it is just installation, then setuptools doesn't overwrite old versions, it basically just "activates" a particular installed version of a library by changing easy-install.pth, and to a degree with .egg-link files. I think .egg-link could be used to even more effect, creating something like stow, except without relying on symlinks specifically. Instead of a series of symlinks like stow uses, setuptools changes the package loading and creates one reference to the installed version. So maybe this is already allowed. There aren't (yet) very good tools for actually switching versions and viewing the available installed versions of packages, but the actual mechanism to do so is fairly straight-forward (just edit that easy-install.pth file, view using a wildcard, remove with a delete). The other stuff we've been talking about is creating an environment that contains all of the packages for some "project" -- maybe a particular web application, a user's local (non-root) Python installation, or whatever.
Here is a (trunicated) tree listing from trac project: /usr/local/stow/trac-svn-r2824 |-- bin |-- lib | `-- python2.3 | `-- site-packages | `-- trac `-- share |-- man | `-- man1 `-- trac
Right now my workaround is to use bdist_egg and then copy the egg into the directory /usr/local/stow/project-version/lib/python2.4/site-packages (which I have to mkdir first). This isn't perfect because I don't get non-egg stuff, if any exists.
There shouldn't be non-egg stuff; if there is, then the package isn't really a good setuptools package. I think setuptools catches attempts to write files elsewhere too, and at least warns about it. While I can understand you want to stick to a stow-based system, at this point stow seems unnecessarily indirect. However, you can always give the -d option or one of the other available options to have easy_install put the egg right where you want it. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org