[Python-Dev] setuptools: past, present, future (original) (raw)

Terry Reedy tjreedy at udel.edu
Sat Apr 22 06:22:51 CEST 2006

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

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

  1. 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 mailing list