[Distutils] creating rpms of setuptools, sqlobject and formencode

[Phillip J. Eby]

At 08:41 AM 10/24/2005 +0200, Pau Aliagas wrote:
>On Sat, 22 Oct 2005, Phillip J. Eby wrote:
>>>I'm the one creating the rpm :) I enclose the spec file.
>>>What it does is this:
>>>python setup.py build
>>>python setup.py install -O1 --skip-build --root $RPM_BUILD_ROOT \
>>>     --record=INSTALLED_FILES.tmp
>>>In INSTALLED_FILES.tmp I cannot see any pth file, so it is not included 
>>>in the rpm, as thes are the files it will include.
>>
>>Hm.  Looks like easy_install isn't writing them to the --record file, 
>>even if it's updating them on disk.  But it also may not be writing them 
>>on disk, due to the use of the --root option.
>
>I've seen what happens, after reading carefully the documentation... and 
>the output of the program: when callling:
>$ python setup.py install -O1 --skip-build --root $RPM_BUILD_ROOT \
>   --record=INSTALLED_FILES.tmp
>
>I add --root, so it considers it's a multi installation and does not 
>create a pth file.
>
>To overcome this, I create a pth file manually and add it to 
>INSTALLED_FILES.tmp. This works.

Great; ideally, though, this should be a single file for all rpm-wrapped 
eggs, say 'rpm-eggs.pth' in the site-packages directory.


>But for the rpms that depend on setuptools, the best way I've found is to 
>use the --old-and-unmanageable option that does not use the eggs dir structure.

I presume you mean for rpms that do *not* depend on setuptools.


>One comment here: the name "--old-and-unmanageable" is not very polite adn 
>I think it should be something like --no-eggs. There's a lot of people 
>putting effort in building rpms for several distributions and I think we 
>should not be offensive.

The setuptools 'bdist_rpm' command has a '--no-egg' option already.  The 
'--old-and-unmanageable' option is for 'install', not 'bdist_rpm'.  It is 
deliberately derogatory because many setuptools-based packages (including 
setuptools itself) simply *will not work* when installed that way, because 
the distribution's metadata cannot be included.


>The trick I've used is to install setuptools with the egg dirs and the pth 
>file, and the rest without. I don't like the install system downloading 
>eggs and installing them in the global dirs if you do it like root! 
>Package tools like rpm should be used instead if we want mantainable systems.

The goals of system packagers and system administrators are quite often at 
odds with the goals of users, application developers and application 
deployers.  However, since the packagers and administrators exist to serve 
the needs of users, not the other way around, I prefer to make matters 
better for the latter group first, and then leverage their desire for 
improved conditions to bring the packagers and administrators into the 
fold.  :)

Note in particular that eggs provide application deployers with a *massive* 
increase in supportability, compared to using native packaging 
systems.  They need only learn one system that can then be used for their 
Python application across Mac, Windows, and every flavor of Linux or 
BSD.  In contrast, a package like TurboGears, that depends on almost a 
dozen other Python packages, would be unsupportable if the author had to 
know the ins and outs of every Linux flavor's packaging system in order to 
check for the availability of dependencies.

Of course, I'm always happy to help packagers and administrators develop 
ways to have their existing packaging systems and packages provide eggs!  I 
just am dealing with it on the passive side.  In the long run, it will be 
easier for packagers to provide all Python packages as eggs, because there 
will eventually be so many packages that either must be an egg to function 
at all, or which require enough other dependencies as eggs that it makes 
more sense to just bite the bullet and build all Python packages as 
eggs.  (Note that any distutils-packaged Python code may be packaged in egg 
form, but not every egg-packaged application can be installed in 
--old-and-unmanageable form.)


>>I think the best thing to do is going to be to follow the experimental 
>>Gentoo egg installation strategy:
>>
>>    http://eggs.gentooexperimental.org/wiki/Overview
>>
>>which adds install/uninstall scripts that add or remove eggs from a 
>>'gentoo-eggs.pth' file.
>
>It sounds interesting, but in an rpm system you only can have one version 
>of each package :(

It would still be better to use a single .pth file for all rpm-deployed 
eggs, to minimize the impact on interpreter start time.  The fact that only 
one version is present at a time is moot because the .pth file only ever 
lists one version at a time anyway.