[Python-Dev] setuptools: past, present, future

[Terry Reedy]

"Phillip J. Eby" <pje at telecommunity.com> wrote in message 
news:5.1.1.6.0.20060421134259.0419f318 at mail.telecommunity.com...

I have some general comments which I will not try to tie to specific 
quotes.

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 
actual addition.

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 
posts.

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 
died.

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