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.