[Distutils] pip vs easy_install vs distutils2

[Tarek Ziadé]

2010/5/29 P.J. Eby <pje at telecommunity.com>:
> At 01:13 AM 5/29/2010 +0200, Tarek Ziadé wrote:
>>
>> The problem I have with this approach is that we need to manage
>> somewhere at PyPI a list of potential installers,
>> and maybe deal with upgrades and replacements. Plus, I am not sure
>> that a user will really understand what to
>> do when he's asked to chose an installer. Sounds like something we
>> should only ask to power users, and
>> people that know what they are doing with p7g. So a bootstrap script
>> is useless for them.
>
> Actually, the way it would (presumably) work would be just a script like
> Guido's that downloads a source archive from PyPI and runs setup.py install.
>  So, it's not really a matter of "choosing" an installer -- it'd just be,
> "download and install a package from source".
>
> If the package itself needs one of those other things in order to build
> itself or install dependencies, then the next stage of bootstrap is its
> problem (e.g. via ez_setup), not the stdlib's.
>
> So, I don't see the "power users only" objection making sense, at least if
> we drop back to what I believe was Guido's original proposal for a bootstrap
> script a few years ago.

I was not thinking about this proposal. If this what Guido proposed at
the summit, then I misunderstood. I was thiking about a bootstrap
process on the end-user side, to set up an installer once for all, on
a fresh Python.

The problem with the feature you describe (bootstrap embed in the
archive itself) is that we imply that the packager chooses himself an
installer and forces the end-user to use it when he installs the
software. This means that the end user might end up with several
installers installed for the same Python. It also implies that the
developer provides a smart setup.py script that embeds that bootstrap,
and runs some code.

I think separating the concerns and letting the end user pick/use
explicitly *one* installer globally is better because several
installers won't compete on the target system (even if we supposely
want them all to be compatible in the future). Of course, this is only
true for source distributions.

It will also allow distributions to be "dumb" envelopes with static
metadata that are the same all the time, no matter which tool created
them, and eventually remove setup.py in favor of statically described
metadata using PEP 345.

Today, for instance, if an installer wants to install a distribution
based on setuptools, it has to run the "egg_info" command to extract
the metadata, on the target system.  Being able to get those metadata
without running any code would be better. For instance, installers
could list all dependencies for a project by querying PyPI with zero
download/execution. (thanks to PEP 345 environment markers)

What would make more sense I think, would be to have all installers an
identical archive for a given project, that doesn't need more code to
be run to get all the metadata.

So at the end, the end user would chose an installer that is
compatible with these archive, and know how to install them. In other
words, have ez_setup for example, run once for all at the Python
level, and be THE installer. Or run a pip_setup or whatever.

Regards,
Tarek
-- 
Tarek Ziadé | http://ziade.org