[Distutils] .egg in Debian summary?
Phillip J. Eby
pje at telecommunity.com
Wed Nov 23 18:35:42 CET 2005
At 12:17 AM 11/23/2005 -0600, Bob Tanner wrote:
>Bob Tanner wrote:
>
> >> I don't think Debian should use the egg structure. It apparently relies
> >> on building a long sys.path (even though through only a single .pth
> >> file);
> >
> > I'm not sure of how .eggs are implemented, but I'm going to cross-post
> > this info to the python-distutils mailing list.
>
>Read and re-read the complete thread regarding .eggs in Debian and I cannot
>tell if any progress has been made.
>
>Still in the discussion/fact-finding stage?
>
>As "just a package maintainer" I was looking for the "options" to move
>forward. Looking at the thread, I think these are the options (skipping the
>pro's and con's for now):
>
>1. Do nothing, go with the status quo as documented in the Debian python
>policy, which is no .egg's and unpackage everything into a sub-directory of
>site-packages.
>
>2. Investigate easydeb <http://cheeseshop.python.org/pypi/easydeb/>
>
>3. Using Phillip's .egg-info solution
><http://permalink.gmane.org/gmane.comp.python.distutils.devel/2567>
>
>Any others?
#1 is pointless if your goal is to get TurboGears packaged. As others have
pointed out, future versions of TurboGears will be depending even more
heavily on egg metadata than the current version does, and many of
TurboGears' dependencies (e.g. SQLObject) already make use of egg metadata
themselves, even if some only need the metadata for the sake of the
projects that use them.
#2 or something like it is the best long-term approach in my view, in that
it supports a more automated packaging process, while avoiding
inter-project name conflicts and properly supporting namespace
packages. Also, under a 'pyegg' namespace, it could also be reasonable to
install some projects such that 'require()' is necessary to use them. But
there are a number of practical hurdles -- including policy decisions --
that keep this option from being a quick and easy choice.
Practically speaking, I think #3 is the best compromise/transitional
option, especially for packaging things like ElementTree, which is not
packaged using setuptools, but which other projects need egg metadata
for. This allows the existing Debian Python packages to be utilized by the
egg system without duplication, since you need only add an empty .egg-info
directory to the existing Debian packages. (Since the only metadata needed
is the project name and version, which can be supplied from the .egg-info
path.)
I double-checked the implementation, and I'm going to have to actually
change setuptools a bit to support this, because currently it doesn't parse
the version from an .egg-info directory name. This is easy to fix, though,
and I can put it out in 0.6a9, along with a
--single-version-externally-managed option for the easy_install and install
commands, and perhaps a bdist_rpm command using the same approach. These
changes shouldn't take long, though. Until then, however, you would have
to create an .egg-info/PKG-INFO file to be compatible with
currently-released versions of setuptools.
More information about the Distutils-SIG
mailing list