On 10.02.2016 19:46, Robert Collins wrote: > On 11 February 2016 at 02:36, M.-A. Lemburg <m...@egenix.com> wrote: > >>> Currently what pip does is to >>> invoke >>> >>> $ python setup.py egg_info --egg-base $TEMPDIR >>> >>> to get the metadata. It is not possible to get the metadata without >>> executing the setup.py which is problematic for many applications. >>> Providing a static pypa.json file is much better: tools can read a >>> static file to get the metadata. >> >> Depends on which kind of meta data you're after. sdist packages >> do include the static PKG-INFO file which has the version 1.0 >> meta data. This doesn't include dependencies or namespace >> details, but it does have important data such as version, >> package name, description, etc. > > For pip to use it, it needs to include - reliably - version, name, and > dependencies; for it to be in any way better, we also need > setup-requires or a functional equivalent. > > Today, we can't rely on the PKG-INFO being complete, so we assume they > are all wrong and start over. One of the things we'll get by being > strict in subsequent iterations is the ability to rely on things.
Then why not fix distutils' sdist command to add the needed information to PKG-INFO and rely on it ? Or perhaps add a new distutils command which outputs the needed information as JSON file and fix the sdist command to call this by default ? There are many ways to address such issues, but defining a new standard for every issue we have instead of fixing the existing distutils implementation is not the best way to approach this. >> In the end, you'll just be defining a different standard >> to express the same thing in different ways. >> >> The setup.py interface was never designed with integration in mind >> (only with the idea to provide an extensible interface; and I'm not >> going get into the merits of setuptools additions such as >> --single-version-externally-managed :-)) but it's still >> quite usable for the intended purpose. > > However we *are defining an integration point*, which is yet another > reason not to use the setup.py interface. https://xkcd.com/927/ :-) setup.py is the current standard and even though it's not necessarily nice, it works well and it does support adding different build systems (among many other things). mxSetup.py, for example, includes a build system for C libraries completely outside the distutils system, based on the standard Unix configure/make dance. It simply hooks into distutils, takes a few parameters and goes off to build things, feeding the results back into the distutils machinery. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Feb 11 2016) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ 2016-01-19: Released eGenix pyOpenSSL 0.13.13 ... http://egenix.com/go86 ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
