On Jun 1, 4:47 am, Alia Khouri <[EMAIL PROTECTED]> wrote: > Can we open up the discussion here about how to improve setuptools > which has become the de facto standard for distributing / installing > python software. I've been playing around with ruby's gems which seems > to be more more mature and usable. > > From my perspective, the relative immaturity of setuptools and its > simultaneous widespread use is a clear python weakness and can make > python less easy to absorb than it should be. > > A few questions (please add more) so far are:
Oh boy. > (1) Should setuptools be standard? Shamelessly speaking as someone who does no wish to enter this particular niche of Python: I would hope the Python community can do better. > (2) What bugs you most about the current featureset? 1. setuptools will download and install dependencies on the user's behalf, without asking, by default. It can be disabled, but I think it's extremely rude: it should ask by default. 2. One cannot simply import modules from packages that use entry_points: you have to go through package resources. Very annoying. 3. Tools such as py2exe don't work with packages that use entry_points except with some hand tweaks (at least as of the last time I tried). One might suggest that py2exe should learn how to include setuptools models, but I don't think people who write tools like py2exe ought to be burdened with it. py2exe was possible because the import mechanism was theretofore so straightforward. FWIW, I've abandoned usage of a package that used entry points because of this issue. > (3) Which features do you need the most (list in order of need)? Not that my needs are all important, but: 1. Works. 2. Ability to install to unusual locations (BIG) 3. Packages can be installed separately by hand if the user so desires (copying to site directory, hand editing if necessary) 4. Ability to easily specify compiler options when rebuilding extension modules. 5. Handles data files reasonably > (4) Shouldn't we just port gems to python? Fine with me, some new blood would be useful here. > (5) What's the best community process to improve setuptools? Have the BDFL declare that it's the official Python package manager. Of course, I hope if it ever comes to that the BDFL will pronounce something else to be the official Python package manager, preferrably something that isn't based on distutils. > Hope this discussion can be constructive. In any case, I do appreciate > the effort that went into creating setuptools (Thanks Phillip J. > Eby :-). It's existence is clearly better than otherwise. I don't agree. It's probably better than otherwise for enterprise applications, which is the environment for which it was designed. For instance, entry points and dependency bookkeeping are useful in such environments, since there are policies to ensure consistent and reasonable usage. For open source, mom-and-pop operations, and other smaller projects, I think it adds a whole lot of complexity over what otherwise is a simple thing. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
