Python's setuptools and the integrated repository, cheeseshop, are now the mainstream way to distribute and update python packages. There are already hundreds of unique packages, with full (or improving) dependency and slotting metadata. An example of the 'problem' is the popular Turbogears web framework package. Portage currently has no good way to install it, AFAIK. TG is pioneering the use of a large collection of dependencies distributed exclusively as .egg files. A single command to setuptools pulls in all these dependencies, in a very portage-like way. Eggs Galore Example http://www.turbogears.org/preview/download/index.html It is apparent that a powerful python script similar to g-cpan.pl is needed. It seems from the man page that g-cpan.pl can 'watch and record' the activities of CPAN installs, and record the metadata as if the package were installing via and actual ebuild. It sounds sort of like a monitor-and-inject capability, and that is exactly what Portage will need to leverage the goodness of setuptools and cheeseshop. In the short term, a good solid eclass needs to land in Portage proper to support manually-created ebuilds for python packages a) distributed as eggs, b) installed with setuptools and c) uploaded to cheeseshop, or any combination of a,b,c. Some fine work has been done at: "Eggs / easy_install / setuptools Project for Gentoo" http://eggs.gentooexperimental.org/ However, the last updates to this overlay occured on or about January 2006. Both setuptools and the collection of cheeseshop eggs have changed substantially since then. Many python packages currently in portage are no longer distributed except as .eggs through cheeseshop. We need the updated and debugged eclass to land in portage proper to be able to submit sensible replacement ebuilds. FYI: setuptools has some issues with installation to /var/tmp/portage/(packagename), since it does some package-install-time checks to see if the destination path is on the python-discoverable path. Opinion: Cheeshop and various project repositories contain some eggs with cruft in the names. People put things like svn revisions, bug/hotfix names, etc. The eclass should help ebuild authors strip the portage metadata, and the .egg file, .pth file, etc, down to the essential components of the name. If at all possible those components should follow the portage ebuild naming guide, since those are great and sensible rules. FYI: http://peak.telecommunity.com/DevCenter/setuptools#install-command provides a portage-friendly way to install python packages using setuptools. You give up a lot of setuptools automatice installation and dependency management (which has always been ably handled by portage, of course), but using --single-version-externally-managed should bridge the gap until something akin to g-cpan.pl is ready, which can 'record' the activities of setuptools as if they were done by actual ebuilds. FYI: .egg files are binary zip files containing all python source, compiled python bytecode, and compiled C extensions for a package. Apparently importing from zip(s) speeds up import execution, but I have reservations about source files being opaque to editors, browsers, etc. I think stepping through debuggers should still yeild source, but do not know for sure. --single-version-externally-managed has the advantage of installing the traditional source in a specified directory. The ultimate solution is probably to have a site-packages and site-packages-source parallel directory tree on 'development' machines, but the python community will have to work that convention out for itself. Thanks! This is a lot to ask, but Gentoo's python package support is likely to fall off the map suddenly if it doesn't get on the setuptools+cheeseshop bandwagon ASAP.
(In reply to comment #0) > An example of the 'problem'... I should clarify that I think setuptools, cheeseshop and eggs in general are anything but a problem, rather they add up to *very* good progress for python development. We can already see a noticeable improvement in release frequency, package discoverability, etc. The 'problem' as such is only that portage has been doing many of these things previously, and now it needs to step back and let setuptools (and CPAN, and ruby gems) do their thing, since these repository mechanisms get all the language community attention.
Let me try to make you understand the apparent lack of progress here (I have done some <snip>s to prevent an extremely huge reply, please poke me if I snipped anything you consider important): (In reply to comment #0) <snip> > An example of the 'problem' is the popular Turbogears web framework package. > Portage currently has no good way to install it, AFAIK. TG is pioneering the > use of a large collection of dependencies distributed exclusively as .egg > files. Not *exclusively* eggs. As far as I can tell source tarballs (with a setuptools setup.py) are available. The distinction between eggs and setuptools-enabled setup.py is important. > A single command to setuptools pulls in all these dependencies, in a > very portage-like way. As far as I know it does not install anything except for the egg (no documentation etc.). If it does install anything else I doubt this is reliably uninstallable (please correct me if I am wrong here). It requires all its dependencies to be eggified (or distutils stuff installed with python 2.5's distutils, which is still some time away). It does not allow other ebuilds to depend on those eggs in a straightforward way. <snip> > It is apparent that a powerful python script similar to g-cpan.pl is needed. It > seems from the man page that g-cpan.pl can 'watch and record' the activities of > CPAN installs, and record the metadata as if the package were installing via > and actual ebuild. It sounds sort of like a monitor-and-inject capability, and > that is exactly what Portage will need to leverage the goodness of setuptools > and cheeseshop. As far as I know (again please correct me if I am wrong, I have not used g-cpan and reading the source is a bit hard since it is written in perl :) g-cpan creates ebuilds, puts them in an overlay, and lets portage do the work. This sounds like something that should be doable for setuptools stuff too, but it might need some slight trickery to deal with dependencies that are not eggified or dependencies that are in portage with a slightly different name. It is somewhere on the TODO list :) > In the short term, a good solid eclass needs to land in Portage proper to > support manually-created ebuilds for python packages > a) distributed as eggs, I am rather heavily against this. Eggs are really not like source tarballs and much more like rpm files. They can contain arbitrary compiled C code, and as far as I know there is no reason not to use the source tarball instead (unless this tarball is not released, in which case the solution is "poke upstream until they release the source tarball non-eggified too" :) > b) installed with setuptools Using very recent versions of setuptools you can just use distutils.eclass to install: --single-version-externally-managed is automagically used by setuptools if the --root option is specified to setup.py, which is what distutils.eclass uses. I have an overlay (emerge bzr and run "bzr get http://dev.gentoo.org/~marienz/bzr/setuptools-overlay" to get it) where I have experimented with this (these are experimental ebuilds, they may kill kittens or do equally nasty things) > and c) uploaded to cheeseshop Just do as in "b) installed with setuptools" and point SRC_URI at pypi :) > or any combination of a,b,c. If I understand correctly the above answers this. > Some fine work has been done at: > "Eggs / easy_install / setuptools Project for Gentoo" > http://eggs.gentooexperimental.org/ I will have a look at that later. Most of it was done by pythonhead who unfortunately for us does not have a lot of time for gentoo at the moment. > However, the last updates to this overlay occured on or about January 2006. > Both setuptools and the collection of cheeseshop eggs have changed > substantially since then. True, but I think the changes are good changes (the automagic --single-version-externally-managed thing) > Many python packages currently in portage are no > longer distributed except as .eggs through cheeseshop. Do you have an example for that? "except through cheeseshop" I understand, but only as eggs? > We need the updated and > debugged eclass to land in portage proper to be able to submit sensible > replacement ebuilds. Please provide examples where distutils.eclass does not suffice. > FYI: setuptools has some issues with installation to > /var/tmp/portage/(packagename), since it does some package-install-time checks > to see if the destination path is on the python-discoverable path. Do you have an example for that? > Opinion: Cheeshop and various project repositories contain some eggs with cruft > in the names. People put things like svn revisions, bug/hotfix names, etc. The > eclass should help ebuild authors strip the portage metadata, and the .egg > file, .pth file, etc, down to the essential components of the name. If at all > possible those components should follow the portage ebuild naming guide, since > those are great and sensible rules. versionator.eclass is your friend here, although we will need something more fancy if the automagic ebuild-generation script like g-cpan sees the light of day. > FYI: http://peak.telecommunity.com/DevCenter/setuptools#install-command > provides a portage-friendly way to install python packages using setuptools. > You give up a lot of setuptools automatice installation and dependency > management You do? Explain please. As far as I understand you lose the ability to have multiple versions installed in parallel (which imho is not *that* important) and gain the ability to just say "import packagename" without any .pths involved (which *is* important to allow non-setuptools packages to depend on setuptools packages). > (which has always been ably handled by portage, of course), but > using --single-version-externally-managed should bridge the gap until something > akin to g-cpan.pl is ready, which can 'record' the activities of setuptools as > if they were done by actual ebuilds. As far as I know they *are* done by actual ebuilds. > FYI: .egg files are binary zip files containing all python source, compiled > python bytecode, and compiled C extensions for a package. Apparently importing > from zip(s) speeds up import execution, but I have reservations about source > files being opaque to editors, browsers, etc. I think stepping through > debuggers should still yeild source, but do not know for sure. That will definitely not be the case unless the debugger is relatively "fancy". You lose the ability to just point an editor at linenumbers in a traceback. <snip> > Thanks! This is a lot to ask, but Gentoo's python package support is likely to > fall off the map suddenly if it doesn't get on the setuptools+cheeseshop > bandwagon ASAP. Final points: after reading the above you are probably wondering why there are not boatloads of distutils.eclass ebuilds for setuptools already if that works so nicely, which is a valid question :) The reason is this only started working with recent versions of setuptools (--single-version-externally-managed was only added a couple of alphas ago, and --root implying --single-version-externally-managed is even more recent). Before that point we would have needed an eclass (or the ebuild having cruft that should be in an eclass, like http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-python/pysqlite/pysqlite-2.0.7.ebuild?hideattic=0&rev=1.7&view=markup does). Although adding such an eclass is not a lot of work, *removing* or making large changes to such an eclass afterwards is impossible or dangerous (see bug 46223). The setuptools version required for "nice" ebuilds is still labeled "alpha", and I would really prefer to wait until it is at least labeled "beta" as some indication that there will be no large changes anymore. As soon as that happens you should see more setuptools-enabled stuff enter the tree. Another point I think should be mentioned: turbogears automagic install only works because they sort of "forked" ElementTree and cElementTree, adding setuptools to the setup.py. For gentoo I would really prefer not to deviate from the upstream package like that (it is up to ElementTree's author to use or not use setuptools). Unfortunately pkg_resources.require('TurboGears') (this is from memory, correct any typos please :) fails if you have (c)ElementTree installed as non-egg. This can be "fixed" by patching out the dependency (and relying on portage to handle it) but this sort of thing may get ugly with the g-cpan script idea. If you want to talk about setuptools/eggs more it may be more appropriate to do so on email (marienz@gentoo.org) or irc (#gentoo-python on freenode) instead of bugzilla.
(In reply to comment #2) > Let me try to make you understand the apparent lack of progress here (I have > done some <snip>s to prevent an extremely huge reply, please poke me if I > snipped anything you consider important): > > (In reply to comment #0) > <snip> > > An example of the 'problem' is the popular Turbogears web framework package. > > Portage currently has no good way to install it, AFAIK. TG is pioneering the > > use of a large collection of dependencies distributed exclusively as .egg > > files. > > Not *exclusively* eggs. As far as I can tell source tarballs (with a setuptools > setup.py) are available. The distinction between eggs and setuptools-enabled > setup.py is important. > Just to clarify, there 2 "types" of eggs. which difer from this flag --exclude-source-files Also and went you have non-pure-python modules this becomes a problems since the C/C++ extensions must be compile in order to make the egg. So some eggs will be troublesome. > > A single command to setuptools pulls in all these dependencies, in a > > very portage-like way. > > As far as I know it does not install anything except for the egg (no > documentation etc.). If it does install anything else I doubt this is reliably > uninstallable (please correct me if I am wrong here). It requires all its > dependencies to be eggified (or distutils stuff installed with python 2.5's > distutils, which is still some time away). It does not allow other ebuilds to > depend on those eggs in a straightforward way. yes your right now there is no uninstall, and cruft builds up in site-packages dir, although a pkg_postrm() function will be easy to implement, since it's just one dir with egg name to delete and eliminate it from the .pth file. > <snip> > > > It is apparent that a powerful python script similar to g-cpan.pl is needed. It > > seems from the man page that g-cpan.pl can 'watch and record' the activities of > > CPAN installs, and record the metadata as if the package were installing via > > and actual ebuild. It sounds sort of like a monitor-and-inject capability, and > > that is exactly what Portage will need to leverage the goodness of setuptools > > and cheeseshop. > > As far as I know (again please correct me if I am wrong, I have not used g-cpan > and reading the source is a bit hard since it is written in perl :) g-cpan > creates ebuilds, puts them in an overlay, and lets portage do the work. This > sounds like something that should be doable for setuptools stuff too, but it > might need some slight trickery to deal with dependencies that are not eggified > or dependencies that are in portage with a slightly different name. It is > somewhere on the TODO list :) unless all gentoo packages are move to a setuptools based instalation, which isn't a bad idea IMO > > > In the short term, a good solid eclass needs to land in Portage proper to > > support manually-created ebuilds for python packages > > > a) distributed as eggs, > > I am rather heavily against this. Eggs are really not like source tarballs and > much more like rpm files. They can contain arbitrary compiled C code, and as > far as I know there is no reason not to use the source tarball instead (unless > this tarball is not released, in which case the solution is "poke upstream > until they release the source tarball non-eggified too" :) pure-python for modules that DO add the source to the egg it's exactly as a tarball they only depend on python version, the problem comes with "dirty" python modules, where eggs do become platform dependant.
(In reply to comment #3) > (In reply to comment #2) > > Not *exclusively* eggs. As far as I can tell source tarballs (with a setuptools > > setup.py) are available. The distinction between eggs and setuptools-enabled > > setup.py is important. > > > > Just to clarify, there 2 "types" of eggs. which difer from this flag > --exclude-source-files > > Also and went you have non-pure-python modules this becomes a problems since > the > C/C++ extensions must be compile in order to make the egg. So some eggs will be > troublesome. I think we misunderstand each other here. What I am talking about is not using the .egg downloads from that page at all, instead using the .tar.gz or .zip downloads, which contain just the source and setup.py, no precompiled stuff at all. Even though most eggs contain the source I think it's preferable to use the actual source-only tarballs, as long as they are available (I am hoping they will normally be available). <snip> > yes your right now there is no uninstall, and cruft builds up in site-packages > dir, > although a pkg_postrm() function will be easy to implement, since it's just one > dir > with egg name to delete and eliminate it from the .pth file. Just using distutils.eclass makes this work completely automagically. > unless all gentoo packages are move to a setuptools based instalation, which > isn't a bad idea IMO I strongly disagree. Gentoo's general policy is to deviate from upstream source as little as possible. It is up to upstream authors to move to setuptools or not. I think it is a bad idea to force setuptools/eggs on stuff like that. Anyway python 2.5 will make this point largely moot by installing some egg-like metadata for everything. > pure-python for modules that DO add the source to the egg it's exactly as a > tarball they only depend on python version, > the problem comes with "dirty" python modules, where eggs do become platform > dependant. If we just use the source tarball this will Just Work, right? Why can we *not* use the source tarball? Is there a downside?
> I think we misunderstand each other here. What I am talking about is > not using the .egg downloads from that page at all, instead using > the .tar.gz or .zip downloads, which contain just the source and > setup.py, no precompiled stuff at all. > Even though most eggs contain the source I think it's preferable to use > the actual source-only tarballs, as long as they are available (I am hoping > they will normally be available). > <snip> > If we just use the source tarball this will Just Work, right? > Why can we *not* use the source tarball? Is there a downside? Unfortunately, source tar.gz distributions are not always available. Setuptools is taking off, and .egg files are sometimes (and increasingly) the only distribution package available. Especially in the case of fast-moving projects like turbogears (which is the driving case for this discussion), there will be no way to poke upstream to make sure there is always parallel tar.gz source releasess for every point and testing snapshot. Look at the turbogears preview download page, it demonstrates many of the issues I raise in this bug: http://www.turbogears.org/preview/download/index.html I don't have a way to survey cheeseshop release file formats, but I expect there is a growing fraction of projects who do not, or will soon not, release .tar.gz or .zip formats. Subversion repositories seem to be an increasingly popular way to make on-demand publication of sources (e.g. svn repository tags). Cheeseshop-integrated .eggs are apparently the coming thing, for better or for occasionally (for externally managed packagers) worse.
Regarding the turbogears preview, there should be an informative event today. The preview is scheduled to release 0.9alpha5, and the packages may update significantly, many in only .egg format. As of 0.9alpha4 at 2006-04-28 10:40 EST, here is the published package list: Download packages (Easy Install uses these) * cElementTree-1.0.5-20051216.tar.gz * cElementTree-1.0.5_20051216-py2.3-macosx-10.4-ppc.egg * cElementTree-1.0.5_20051216-py2.3-win32.egg * cElementTree-1.0.5_20051216-py2.4-macosx-10.4-ppc.egg * cElementTree-1.0.5_20051216-py2.4-win32.egg * Cheetah-1.0-py2.4-macosx-10.4-ppc.egg * Cheetah-1.0-py2.4-win32.egg * Cheetah-1.0.tar.gz * CherryPy-2.2.1-py2.3.egg * CherryPy-2.2.1-py2.4.egg * ConfigObj-4.3.0-py2.3.egg * ConfigObj-4.3.0-py2.4.egg * elementtree-1.2.6-py2.3.egg * elementtree-1.2.6-py2.4.egg * FormEncode-0.4-py2.3.egg * FormEncode-0.4-py2.4.egg * kid-0.9.1-py2.3.egg * kid-0.9.1-py2.4.egg * Lightbox-2.0-py2.4.egg * Lightbox-2.0a1-py2.4.egg * nose-0.8.6-py2.4.egg * Paste-0.5-py2.3.egg * Paste-0.5-py2.4.egg * PasteScript-0.5-py2.3.egg * PasteScript-0.5-py2.4.egg * PyProtocols-1.0a0dev_r2082-py2.3-macosx-10.4-ppc.egg * PyProtocols-1.0a0dev_r2082-py2.3-win32.egg * PyProtocols-1.0a0dev_r2082-py2.4-macosx-10.4-ppc.egg * PyProtocols-1.0a0dev_r2082-py2.4-win32.egg * PyProtocols-1.0a0dev_r2082.zip * pYsearch-2.0-py2.4.egg * RuleDispatch-0.5a0.dev-r2115.tar.gz * RuleDispatch-0.5a0.dev_r2115-py2.3-macosx-10.4-ppc.egg * RuleDispatch-0.5a0.dev_r2115-py2.3-win32.egg * RuleDispatch-0.5a0.dev_r2115-py2.4-macosx-10.4-ppc.egg * RuleDispatch-0.5a0.dev_r2115-py2.4-win32.egg * Scriptaculous-1.6-py2.4.egg * Scriptaculous-1.6a1-py2.4.egg * setuptools-0.6a11-py2.3.egg * setuptools-0.6a11-py2.4.egg * simplejson-1.3-py2.3.egg * simplejson-1.3-py2.4.egg * SQLObject-0.7.1dev_r1675-py2.3.egg * SQLObject-0.7.1dev_r1675-py2.4.egg * TGFastData-0.9a3-py2.3.egg * TGFastData-0.9a3-py2.4.egg * TurboBOB-1.0-py2.4.egg * TurboCheetah-0.9.5-py2.3.egg * TurboCheetah-0.9.5-py2.4.egg * TurboGears-0.9a4-py2.3.egg * TurboGears-0.9a4-py2.4.egg * TurboGears-0.9a4.tar.gz * TurboJson-0.9.1-py2.3.egg * TurboJson-0.9.1-py2.4.egg * TurboKid-0.9.4-py2.3.egg * TurboKid-0.9.4-py2.4.egg Sometime Friday 2006-04-28, this should list new packages.
(In reply to comment #5) > > I think we misunderstand each other here. What I am talking about is > > not using the .egg downloads from that page at all, instead using > > the .tar.gz or .zip downloads, which contain just the source and > > setup.py, no precompiled stuff at all. > > Even though most eggs contain the source I think it's preferable to use > > the actual source-only tarballs, as long as they are available (I am hoping > > they will normally be available). > > <snip> > > If we just use the source tarball this will Just Work, right? > > Why can we *not* use the source tarball? Is there a downside? > > Unfortunately, source tar.gz distributions are not always available. Setuptools > is taking off, and .egg files are sometimes (and increasingly) the only > distribution package available. > You both got a point yes using the tar is possible (easier?) but egg files are taking off and many projects are Mainly distrubuted as eggs. > Especially in the case of fast-moving projects like turbogears (which is the > driving case for this discussion), there will be no way to poke upstream to > make sure there is always parallel tar.gz source releasess for every point and > testing snapshot. > That is not true, I have direct access to the proj, and we can ask for a tarball in any way. For example http://files.turbogears.org/eggs/TurboGears-0.9a4.tar.gz now that is just a zip of the svn co. > Look at the turbogears preview download page, it demonstrates many of the > issues I raise in this bug: > > http://www.turbogears.org/preview/download/index.html > > I don't have a way to survey cheeseshop release file formats, but I expect > there is a growing fraction of projects who do not, or will soon not, release > .tar.gz or .zip formats. Subversion repositories seem to be an increasingly > popular way to make on-demand publication of sources (e.g. svn repository > tags). > There you have a point we should support it. > Cheeseshop-integrated .eggs are apparently the coming thing, for better or for > occasionally (for externally managed packagers) worse. >
> > Especially in the case of fast-moving projects like turbogears (which is the > > driving case for this discussion), there will be no way to poke upstream to > > make sure there is always parallel tar.gz source releasess for every point and > > testing snapshot. > > > That is not true, I have direct access to the proj, and we can ask for a > tarball in any way. For example > http://files.turbogears.org/eggs/TurboGears-0.9a4.tar.gz Right, I didn't mean turbogears proper, tg has always provided the .tar.gz (thanks), its the specific dependencies that are sometimes .egg-only
Can you point me at some egg-only dependencies? While the setuptools-enabled version is occasionally only available through that turbogears page I've been able to find "proper" tarballs for everything else for the turbogears version in my overlay I mentioned earlier (dev.gentoo.org/~marienz/bzr/setuptools-overlay).
A new python product PythonEggTools wraps easy_install with an apt-get and apt-cache inspired command interface. PythonEggTools provides functionality which could possibly be wrapped and reused by Portage, or inspire some portage-specific tool or functions for an eggs-aware eclass. Just an FYI. # easy_install PythonEggTools Searching for PythonEggTools Reading http://www.python.org/pypi/PythonEggTools/ Reading http://www.python.org/pypi/PythonEggTools/1.0a0 Best match: PythonEggTools 1.0a0 Downloading http://cheeseshop.python.org/packages/2.4/P/PythonEggTools/PythonEggTools-1.0a0-py2.4.egg#md5=16b1b16420ee0af12b923157e2b92a3c Processing PythonEggTools-1.0a0-py2.4.egg Moving PythonEggTools-1.0a0-py2.4.egg to /usr/lib/python2.4/site-packages Adding PythonEggTools 1.0a0 to easy-install.pth file Installing pet-cache script to /usr/bin Installing pet-get script to /usr/bin Installed /usr/lib/python2.4/site-packages/PythonEggTools-1.0a0-py2.4.egg Processing dependencies for PythonEggTools # pet-get --help Usage: pet-get [options] upgrade pet-get [options] install|remove pkg1 [pkg2 ...] pet-get [options] update pkg1 [pkg2 ...] pet-get [options] source pkg1 [pkg2 ...] pet-get is a simple command line interface for downloading and managing Python packages. It wraps setuptool's 'easy_install' script and accepts the same options. Commands: install - Install new packages update - Update packages to the latest version upgrade - Update ALL packages remove - De-activate a package source - Install editable packages in the current directory We will now print the options from 'easy_install' that may be passed to pet-get: Global options: --verbose (-v) run verbosely (default) --quiet (-q) run quietly (turns verbosity off) --dry-run (-n) don't actually do anything --help (-h) show detailed help message Options for 'easy_install' command: --prefix installation prefix --zip-ok (-z) install package as a zipfile --multi-version (-m) make apps have to require() a version --upgrade (-U) force upgrade (searches PyPI for latest versions) --install-dir (-d) install package to DIR --script-dir (-s) install scripts to DIR --exclude-scripts (-x) Don't install scripts --always-copy (-a) Copy all needed packages to install dir --index-url (-i) base URL of Python Package Index --find-links (-f) additional URL(s) to search for packages --delete-conflicting (-D) no longer needed; don't use this --ignore-conflicts-at-my-risk no longer needed; don't use this --build-directory (-b) download/extract/build in DIR; keep the results --optimize (-O) also compile with optimization: -O1 for "python -O", -O2 for "python -OO", and -O0 to disable [default: -O0] --record filename in which to record list of installed files --always-unzip (-Z) don't install as a zipfile, no matter what --site-dirs (-S) list of directories where .pth files work --editable (-e) Install specified packages in editable form --no-deps (-N) don't install dependencies --allow-hosts (-H) pattern(s) that hostnames must match usage: pet-get [options] requirement_or_url ... or: pet-get --help
(In reply to comment #10) > A new python product PythonEggTools wraps easy_install with an apt-get and > apt-cache inspired command interface. PythonEggTools provides functionality > which could possibly be wrapped and reused by Portage, or inspire some > portage-specific tool or functions for an eggs-aware eclass. Just an FYI. That seems more like a tool for someone that doesn't wants to learn a new set of commands easy_install has never been a problem here. In fact bringing that in will just be another layer on top not really a solution. Now that I re-read this after some time I have some points that have changed a bit. I have to agree with Marien here that the current setup.py files are 100% usable with the current eclass, and that until today there is no setuptools enable package that doesn't works with it (at least I haven't found it) But I still think the concern Jeff pointed out that egg files are becoming "the" way to distribute python packages *both source and binary eggs) is going to be a problem when the only way to get plain old tar.gz will be thru a svn checkout or something similar. So I have to say (again) that maybe something like g-cpan is the best option (in the long run) here.
How about app-portage/g-pypi from the pythonhead overlay? It doesn't yet work on my AMD64, but that's merely an obstacle, no blocker (since it does state explicitely that it doesn't work here).
I wrote a fix for g-pypi and a wrapper, which does single-command installing using g-pypi and some simple shell commands. http://pypi.python.org/pypi/babtools_gentoo Maybe that helps a bit.
Marking WONTFIX because our current distutils eclass works fine now with setuptools. Any issues we had with setuptools were addressed upstream or we figured out how to work with. So far we haven't had a single report of anyone distributing eggs and not distributing a source package. If someone uploads only an egg, they are using distutils, and distutils can create a source tarball automatically too. There's really no reason for anyone not to upload both. Even if a few projects distributed eggs only and refused to upload a tarball, we'd make a source snapshot because eggs don't contain tests, documentation, examples, a setup.py and they'd be a pain to unpack and apply patches etc. As for a g-cpan type of program, as mentioned, we now have g-pypi which will be in portage soon. If anyone wants to help out, development is open to all: http://code.google.com/p/g-pypi/
