[Distutils] pip vs easy_install vs distutils2

[Tarek Ziadé]

On Sat, May 29, 2010 at 6:32 PM, P.J. Eby <pje at telecommunity.com> wrote:
[..]
>
> So?  It's not like they're going to accidentally run 'easy_install' when
> they meant to type 'pip', or vice versa.  ;-)

They will accidentally run easy_install through a simple "python
setup.py install" call if the given project bootstraps ez_setup and
uses setuptools' easy_install command.

The end-user is not asked in the process you describe, what installer
he wants to use. It's implicitly done.

That's the point I am trying to express: it's "implicit, embed,
installers in project's setup.py" vs "an installer globally installed,
knowing how to install projects that follows a given standard"

Some project with ez_setup.py embed will get installed using
setuptools own standard, and will also install setuptools of course in
the end-user Python system.

PEP 345 adds what setuptools had in its own standard on the top of
distutils metadata, and one of the goal now is to be able to rely on
this new standard without having to embed your own installer and hook
it in your setup.py.

I mean, why would we have different metadata standards ? with should
we have different installers that are not interoperable ? why should
people need to add some code in their setup.py to make sure their
stuff is correctly installed ?


>
>> It also implies that the
>> developer provides a smart setup.py script that embeds that bootstrap,
>> and runs some code.
>
> Only if they need something beyond what the distutils provide.

So what will happen when people uses the new metadata 1.2 ? (PEP 345)

I know I don't want to ask the developer to add a special bootstrap in their
project just because they used PEP 345 fields. That's the PEP 345-compatible
installers job.

>
>> 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.
>
> For packages with complex build requirements or distutils extensions (e.g.
> numpy), this is unlikely to happen any time soon.
>
> Conversely, for packages where this *is* the case, the current distutils is
> adequate, and having a bootstrapper that can install them would be a win.

I don't understand where the win is in this case.

For me there are two distinct things:
  - python projects, following some standards and conventions
  - installers, that know how to install projects that follow some
standards and conventions


>
>
>> 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.
>
> It's a good thing Guido loaned me the time machine so I could go back to
> 2005 and fix that one, then:
>
>  http://svn.python.org/view/sandbox/trunk/setuptools/setuptools/command/sdist.py?view=diff&r1=41093&r2=41094
>
> Five years should be long enough ago that by now all the setuptools-based
> source distributions on PyPI today will already have the metadata you
> need...  so when you go back and try again to build your new installer
> today, it will already be there for you to use.  Just download any random
> setuptools-based sdist from PyPI and run "tar -tzf" or "unzip -v" on it to
> see!

This egg-info is useless AFAIK. The egg_info command *has* to be run
again because it
can change depending on the running platform and the code in setup.py.
The one in the source distribution is not guaranteed to be accurate.

Moreover, you can't get them at PyPI unless you download the tarball.

PEP 345 is different in that aspect because environment-specific metadata fields
can be described. And, you can query those metadata at PyPI.

As a matter of fact it's already the case: PyPI is now Metadata 1.2 compatible.
You can do XML-RPC queries at PyPI to get the metadata 1.2 fields (so
the dependencies) for the Distutils2 project.

Regards
Tarek

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