Bug 256541 - RFE: Add setuptools information, i.e. an egg-info directory.
Summary: RFE: Add setuptools information, i.e. an egg-info directory.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: python-docutils
Version: 7
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Toshio Ernie Kuratomi
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-08-27 14:26 UTC by Thomas Moschny
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Fixed In Version: 0.4-7.fc7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-10-08 15:00:37 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
use setuptools during build and install, and add the egg-info dir to the %files section (1.18 KB, patch)
2007-08-27 14:26 UTC, Thomas Moschny
no flags Details | Diff

Description Thomas Moschny 2007-08-27 14:26:27 UTC
Version-Release number of selected component:
python-docutils-0.4-6.fc7

Additional info:
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 
step.

Comment 1 Thomas Moschny 2007-08-27 14:26:27 UTC
Created attachment 173581 [details]
use setuptools during build and install, and add the egg-info dir to the %files section

Comment 2 Toshio Ernie Kuratomi 2007-08-28 04:50:01 UTC
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
using setuptools?
  - 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?

Comment 3 Toshio Ernie Kuratomi 2007-08-31 22:45:10 UTC
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:
  http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs

If you want to attend the meeting, details of when we meet is here:
  http://fedoraproject.org/wiki/Packaging/Committee

Comment 4 Thomas Moschny 2007-09-03 18:51:34 UTC
Well, I don't know setuptools enough to really answer your questions in an 
authorative manner.

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 
upstream?

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 
using setuptools?

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 
providing.

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 
that.

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 
http://trac.edgewall.org/ticket/4994.)


Comment 5 Toshio Ernie Kuratomi 2007-09-06 16:34:40 UTC
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.

Comment 6 Toshio Ernie Kuratomi 2007-09-20 21:57:35 UTC
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?

Comment 7 Thomas Moschny 2007-09-27 15:24:05 UTC
<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.

Comment 8 Toshio Ernie Kuratomi 2007-09-27 22:36:26 UTC
> <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::

  http://fedoraproject.org/wiki/Packaging/Python/Eggs

Comment 9 Fedora Update System 2007-09-28 21:21:07 UTC
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.

Comment 10 Fedora Update System 2007-10-08 15:00:36 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.