[Distutils] Ensuring source availability for PyPI entries / PEP: Build system abstraction for pip/conda etc

[M.-A. Lemburg]

On 10.02.2016 19:46, Robert Collins wrote:
> On 11 February 2016 at 02:36, M.-A. Lemburg <mal at 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/