creating rpms of setuptools, sqlobject and formencode
I'm trying to create rpms for sqlobject, as I've been doing for a while, but since it works with setuptools, I'm unable to do it properly. sqlobject requires formencode and also requires setuptools. If I build he rpm with the attached specs, it downloads both of them and packs them in the same rpm. This is part of the output: + /usr/bin/python setup.py build --------------------------------------------------------------------------- This script requires setuptools version 0.6a5 to run (even to display help). I will attempt to download it for you (from http://cheeseshop.python.org/packages/2.3/s/setuptools/), but you may need to enable firewall access for this script first. I will start the download in 15 seconds. --------------------------------------------------------------------------- Downloading http://cheeseshop.python.org/packages/2.3/s/setuptools/setuptools-0.6a5-py2.... But it is installed in: /usr/lib/python2.3/site-packages/setuptools-0.6a6-py2.3.egg What do I want? I want to create an rpm of setuptools, install it and then, I'd expect setuptools to find it. I've tried it, I've built the setupttols rpm, installed it (it goes in the site-packages dir), but still setup.py does not find it :( and adds it to the rpm. The same happens with formencode. My question is: how can I create an rpm of setuptools that sqlobject can find when setup.py build is executed? What am I doing wrong? Thanks for your help. -- ____________________________________ Pau Aliagas (((smsARENA smsarena.com Tel. 902010292 ____________________________________
At 08:22 PM 10/21/2005 +0200, Pau Aliagas wrote:
I'm trying to create rpms for sqlobject, as I've been doing for a while, but since it works with setuptools, I'm unable to do it properly.
sqlobject requires formencode and also requires setuptools. If I build he rpm with the attached specs, it downloads both of them and packs them in the same rpm.
This is part of the output:
+ /usr/bin/python setup.py build --------------------------------------------------------------------------- This script requires setuptools version 0.6a5 to run (even to display help). I will attempt to download it for you (from http://cheeseshop.python.org/packages/2.3/s/setuptools/), but you may need to enable firewall access for this script first. I will start the download in 15 seconds. --------------------------------------------------------------------------- Downloading http://cheeseshop.python.org/packages/2.3/s/setuptools/setuptools-0.6a5-py2....
But it is installed in: /usr/lib/python2.3/site-packages/setuptools-0.6a6-py2.3.egg
Is /usr/bin/python the same Python 2.3? Try this: /usr/bin/python -c "import sys; print sys.path" If the output of this command doesn't include the setuptools egg, then /usr/bin/python isn't the right Python to use.
On Fri, 21 Oct 2005, Phillip J. Eby wrote:
+ /usr/bin/python setup.py build --------------------------------------------------------------------------- This script requires setuptools version 0.6a5 to run (even to display help). I will attempt to download it for you (from http://cheeseshop.python.org/packages/2.3/s/setuptools/), but you may need to enable firewall access for this script first. I will start the download in 15 seconds. --------------------------------------------------------------------------- Downloading http://cheeseshop.python.org/packages/2.3/s/setuptools/setuptools-0.6a5-py2....
But it is installed in: /usr/lib/python2.3/site-packages/setuptools-0.6a5-py2.3.egg
Everything is installed in: /usr/lib/python2.3/site-packages/setuptools-0.6a5-py2.3.egg/
Is /usr/bin/python the same Python 2.3? Try this:
/usr/bin/python -c "import sys; print sys.path"
If the output of this command doesn't include the setuptools egg, then /usr/bin/python isn't the right Python to use.
This is it, there's the path to site-packages, not directly to the egg. $ /usr/bin/python -c "import sys; print sys.path" ['', '/home/pau/include', '/var/www/html/include_parametres', '/var/www/html/include', '/usr/lib/python23.zip', '/usr/lib/python2.3', '/usr/lib/python2.3/plat-linux2', '/usr/lib/python2.3/lib-tk', '/usr/lib/python2.3/lib-dynload', '/usr/lib/python2.3/site-packages', '/usr/lib/python2.3/site-packages/Numeric', '/usr/lib/python2.3/site-packages/PIL', '/usr/lib/python2.3/site-packages/gtk-2.0'] What am I doing wrong? -- Pau
At 06:30 PM 10/22/2005 +0200, Pau Aliagas wrote:
On Fri, 21 Oct 2005, Phillip J. Eby wrote:
+ /usr/bin/python setup.py build --------------------------------------------------------------------------- This script requires setuptools version 0.6a5 to run (even to display help). I will attempt to download it for you (from http://cheeseshop.python.org/packages/2.3/s/setuptools/), but you may need to enable firewall access for this script first. I will start the download in 15 seconds. --------------------------------------------------------------------------- Downloading http://cheeseshop.python.org/packages/2.3/s/setuptools/setuptools-0.6a5-py2.... But it is installed in: /usr/lib/python2.3/site-packages/setuptools-0.6a5-py2.3.egg
Everything is installed in: /usr/lib/python2.3/site-packages/setuptools-0.6a5-py2.3.egg/
How did you install it there? Via easy_install, or using some other process? I suspect that you installed it some way that didn't include the setuptools.pth file. Check for a /usr/lib/python2.3/site-packages/setuptools.pth file. It's probably missing. Alternately, you might see if there is an easy-install.pth, or some other .pth file that points to the setuptools egg. If there is none, I'm guessing you installed a broken RPM or other broken packaging of setuptools, and you should report the problem to whoever packaged it.
On Sat, 22 Oct 2005, Phillip J. Eby wrote:
Everything is installed in: /usr/lib/python2.3/site-packages/setuptools-0.6a5-py2.3.egg/
How did you install it there? Via easy_install, or using some other process? I suspect that you installed it some way that didn't include the setuptools.pth file.
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.
Check for a /usr/lib/python2.3/site-packages/setuptools.pth file. It's probably missing. Alternately, you might see if there is an easy-install.pth, or some other .pth file that points to the setuptools egg.
You are right, no pth file included, not a single one.
If there is none, I'm guessing you installed a broken RPM or other broken packaging of setuptools, and you should report the problem to whoever packaged it.
How can I make the pth appear when executing the "python setup.py install" command? Should I execute something else? I'm using the standard Fedora template for creating python rpms. Thanks a lot for your help! -- Pau
At 08:08 PM 10/22/2005 +0200, Pau Aliagas wrote:
On Sat, 22 Oct 2005, Phillip J. Eby wrote:
Everything is installed in: /usr/lib/python2.3/site-packages/setuptools-0.6a5-py2.3.egg/
How did you install it there? Via easy_install, or using some other process? I suspect that you installed it some way that didn't include the setuptools.pth file.
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. There's actually a bigger issue, too, which is that the contents of those .pth files are going to be based on the --root, rather than where they'll be really installed on the target system. Ugh. 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. I'd happily accept patches for the bdist_rpm command provided by setuptools, so that setuptools-using packages (including setuptools itself) can build rpms that update an 'rpm-eggs.pth' file.
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. 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. 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. Having a package in rpm form in a distribution like Fedora, make it much more successful and wider used. I like the idea of being able to install multiple versions of a program, the idea of installing in a private directory, but the most common use is to install only one version in the system, at least when things are stable. This should be made easy and, in my opinion, it is not. 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.
There's actually a bigger issue, too, which is that the contents of those .pth files are going to be based on the --root, rather than where they'll be really installed on the target system. Ugh.
I created it by hand inside the spec file, as explained above.
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 :(
I'd happily accept patches for the bdist_rpm command provided by setuptools, so that setuptools-using packages (including setuptools itself) can build rpms that update an 'rpm-eggs.pth' file.
I'll see if I can do something, the spec files can be automatically created from the egg info. Thanks Pau -- Pau
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.
participants (3)
-
Pau Aliagas
-
Pau Aliagas
-
Phillip J. Eby