On Sat, May 29, 2010 at 6:32 PM, P.J. Eby <p...@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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
