[Python-Dev] setuptools: past, present, future
tjreedy at udel.edu
Sat Apr 22 06:22:51 CEST 2006
"Phillip J. Eby" <pje at telecommunity.com> wrote in message
news:18.104.22.168.0.20060421134259.0419f318 at mail.telecommunity.com...
I have some general comments which I will not try to tie to specific
1. Based on comments on c.l.py, the biggest legitimate fact-based (versus
personal-taste-based) knock again Python versus, in particular, Perl is the
lack of a CPAN-like facility. As I remember, there have even been a few
people say something like "I like Python the language better that Perl, but
I won't switch because I love CPAN even more." So I think easier code
reuse will boost Python usage.
2. Some think that PEPs are not needed once Guido approves something, on
the view that the main purpose of a PEP is to host a discussion to help him
decide. But I think you would have slept better if you had written a short
PEP explaining the meaning of 'possible addition' and the implication of
Regardless of the past, I think you should soon (when rested ;-) condense
this down to a PEP 'Upgrading Disutils with Setuptools'. Make separate
sections for 2.5 upgrades and 2.6 plans. Include the 'uncontroversial
tasks' from your later post. Reference this and a few other relevant
3. I think must of the hostility expressed at setuptools really ought to be
directed at the multiplicity of x86 *nix distribution formats, which I
believe significantly inhibits the market for non-Windows systems.
History: I started microcomputing with a Z80 CP/M machine that, like
others, had one of numerous vendor-specific, slightly incompatible,
technically unneeded, user-contemptuous, 5-1/4 floppy formats. So 3rd
party software distribution was difficult (crippled), -- and all those
vendors eventually died.
A few years later my employer got a desktop Motorola 68000 Unix system
mostly to run a specific package. It was a wonderful system, in some
respects a couple of decades ahead of DOS and later Windows. But the
vendors copied the CP/M mistake, making third-party software distribution
across multiple systems non-existent -- and as far as I know, they all
So I think a write-one-setup, distribute-everywhere system would be great.
4. Why can't you remove the heuristic and screen-scrape info-search code
from the easy_install client and run one spider that would check
new/revised PyPI entries, search for missing info, insert it into PyPI when
found (and mark the entry eggified), or email the package author or a human
search volunteer if it does not find enough?
Terry Jan Reedy
More information about the Python-Dev