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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com