Red Hat Bugzilla – Bug 256541
RFE: Add setuptools information, i.e. an egg-info directory.
Last modified: 2007-11-30 17:12:14 EST
Version-Release number of selected component:
This package doesn't contain an egg-info directory, and thus cannot be
accessed via setuptools mechanisms; e.g. newer versions of trac rely on
setuptools to locate and find packages.
The attached fixes this by preloading setuptools in the build and install
Created attachment 173581 [details]
use setuptools during build and install, and add the egg-info dir to the %files section
I'm inclined to close this as WONTFIX as this should be done upstream. If trac
is requiring something that upstream docutils is not providing then trac's build
scripts are broken and we should be persuading trac that they shouldn't be
relying on (what's essentially an API) that docutils is not providing. In the
past we've patched the TurboGears setup.py to not require packages which did not
use setuptools upstream. There's two considerations that make this not an
absolute position, however:
1) If you do get upstream to implement eggs, I'm willing to backport egg support
from the subversion repository to our package.
2) I'm currently revising the python guidelines regarding eggs. We need eggs in
the distro in a relatively few places to support multiple versions of a package
installed concurrently. These revisions currently only address packages which
use setuptools upstream.
Your patch makes it look as though eggs can be implemented relatively easily
from the commandline rather than having to modify upstream's setup.py script.
This makes it somewhat attractive to create eggs in the required packages
(docutils in this case.) On the other side of the equation, however, is the
fact this encourages the bad habit of depending on egg info which is not
provided by upstream. So a few questions to help clarify:
* Are other distros implementing eggs for packages that don't have them upstream?
* Is it as easy as your patch for any distutils using package?
* Is it easy to do this for non-distutils using packages?
* Are there known deficiencies of this method?
- Is information which is optional in setup.py under distutils mandatory when
- Does it present a false sense of completeness? (For instance, docutils
optionally requires python-imaging. Is this information not recorded in the egg
when creating the egg info via this method?)
Any other pros, cons, and general questions you can think of?
The packaging meeting is on Tuesday. If you are in favor of adding egg-info to
packages which do not have it upstream, please add information here soon.
The Draft guideline that we will be voting on is here:
If you want to attend the meeting, details of when we meet is here:
Well, I don't know setuptools enough to really answer your questions in an
As it seems, though, many python packages are installable via easy_install,
into eggs. Amongst these, there are packages like docutils that don't use
setuptools in the first place (e.g. because they want to remain compatible
with Python < 2.3).
Furthermore, it seemed to me that setuptools aims at being backwards
compatible with distutils. So in theory, preloading setuptools as shown in the
patch shouldn't do any harm.
> * Are other distros implementing eggs for packages that don't have them
Only had a quick look. python-docutils in doesn't have an egg-info; OpenSuSE's
rpm has an .egg-info file.
> Is it as easy as your patch for any distutils using package?
See above. I guess so, yes.
> Is it easy to do this for non-distutils using packages?
Probably not. How many of those packages are there?
> Is information which is optional in setup.py under distutils mandatory when
Don't know, but as setuptools seems to aim at being backwards compatible, I
wouldn't expect that.
> Does it present a false sense of completeness? (For instance, docutils
optionally requires python-imaging. Is this information not recorded in the
egg when creating the egg info via this method?)
This seems to be a valid concern. Docutils does not formally specify this soft
dependency, and thus it is not recorded. It's probably up to the packager to
take care of that.
> If trac is requiring something that upstream docutils is not providing then
trac's build scripts are broken and we should be persuading trac that they
shouldn't be relying on (what's essentially an API) that docutils is not
Not sure whether I agree with that. The (packaging) API is not provided by the
packages itself, but by setuptools. If a package is not providing the
necessary information, or in a different format, the packager can correct
As long as there is an established way of installing packages so that the
necessary information is provided afterwards, i.e. via easy_install, we can
hardly convince trac people to 'fix' something. (In fact, it's not only the
build script, but also a problem at runtime, see
Today I'm looking into whether reenabling python2.5's distutils/egg-info
generation will solve this. If it does, I'll CC the python maintainer for input
on whether enabling the default distutils egg generation will cause any problems.
For <F-8 I'll be adding this using approximately your recipe. Hopefully for
F-9+ we'll use the facilities provided by upstream python's distutils. For what
Fedora releases are you looking for this change to be made?
<F8 and F-9+ does seem to exclude F8, but I don't think that was intended ;)
Anyway, I'd like to see egg-info for this package (and others, like spambayes)
for F7 and above.
> <F8 and F-9+ does seem to exclude F8, but I don't think that was intended ;)
Right :-) <=F-8, F-9+.
I've rebuilt with egg-info for F-7 and pushed to testing. I'll let it sit there
for a week or so before promoting to stable unless other people bang on it and
give it good karma.
F-8 is built and I have to send a message to releng to get it added to the F-8
release tag otherwise it will come out as an update right after F-8 releases.
The Python Egg draft has been approved so you can feel free to read it and point
other maintainers at it when requesting they build egg-info for their packages.
Sometime this week I'll move it out of PackagingDrafts/PythonEggs to::
python-docutils-0.4-7.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
python-docutils-0.4-7.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.