[Distutils] Some negative press for easy_install

[Ian Bicking]

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 at colorstudy.com  /  http://blog.ianbicking.org