[Distutils] [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Kevin Turner]

On Wed, 2008-03-19 at 22:18 -0600, zooko wrote:
> 1.  "The very notion of package dependency resolution and  
> programmable or command-line installation of packages at the language  
> level is a bad notion."
> 
> This can't really be the case.  If the existence of such  
> functionality at the programming language level were an inherently  
> bad notion, then we would be hearing some complaints from the Ruby  
> folks, where the Gems system is standard and ubiquitous.  We hear no  
> complaints -- only murmurs of satisfaction.

Okay then, just to fill out your sample -- as the maintainer of a Python
library which is ported to Ruby, I complain equally about eggs and gems.
This isn't really the place for it, but as near as I can tell, the use
of gems requires you to know whether the user has installed your
dependency in the system install or through a gem *at the time you write
your code*, so you know whether to write "require 'dep'" or "require
'rubygems'; gem 'dep'".  This is, IMHO, even worse than the "setuptools
breaks PYTHONPATH" complaint you cited.

> Note that Ruby software is not too hard to include in operating  
> system packaging schemes -- my Ubuntu Hardy apt-cache shows plenty of  
> Ruby software.

Yes, but that software is not installed using the gem management system,
as I confirmed with a recent conversation with my package manager while
we were talking about http://bugs.debian.org/470282 , a quirk which was
hopefully a one-time API breakage, but certainly has not endeared me to
rubygems any further.

I'm sure we could find other people to complain if we look around a
little more.  I know I have commiserators out there.

But, stepping back a bit:

You're right in believing that it is neigh impossible to distribute Ruby
software without providing gems.  So much of your userbase expects it,
especially when you're distributing a library which their applications
will in turn depend on, because *their* users will expect gems, and they
need to be able to use gems to install the dependency.

setuptools seems to perform slightly better here, as, by merely making
sure my pypi entry has a reachable download_url, my package seems to be
available for installation by setuptools users.  Nonetheless, I get a
recurring stream of requests for egg distribution from people who
believe eggs have manifest destiny, and as we heard recently, that "the
controversy is over."

Meanwhile, I beg their continued forgiveness for being hesitant to
require my users to use something not in the standard library for
something as fundamental as "setup.py install."

These folks are the same who gave me bug reports when I put a .tar.bz2
link to my pypi entry, because apparently -- even though bz2 extraction
has been a feature of GNU tar for years -- setuptools (which uses the
standard library tarfile module) on some platforms cannot uncompress bz2
packages.  

the conclusion I am trying to reach here is this:

as a Python package maintainer, I have no idea what the hell to do to
satisfy my users, from those who are using python 2.3 and have no desire
for any new packaging or import semantics, to those who don't mind
having a new ez_setup downloaded on install.  The people who have found
advantages to using the egg-based distribution system are not going
away.  Providing something in the standard library will provide clear
guidance for me, and relieve me of the fear that I am pushing surprising
(<cough>.pth</cough>) or non-standard installation behavior on my users.

so, I hope you work something out.

Love,

 - Kevin