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

[M.-A. Lemburg]

On 10.02.2016 11:08, Paul Moore wrote:
> On 10 February 2016 at 09:34, M.-A. Lemburg <mal at egenix.com> wrote:
>> I'm not sure I'm parsing your comment correctly, but if you are
>> suggesting that PyPI should no longer allow supporting
>> non-open-source packages, this is definitely not going to
>> happen.
> 
> Not at all.

That's good to know :-)

> Although as far as I know the number of closed-source packages
> on PyPI is vanishingly small...
>
> My concern is that we seem to be opening up the option of using
> non-setuptools build systems without having a good solution for people
> *wishing* to upload sources. It's more a matter of timing - if we
> allow people to use (say) flit for their builds then presumably a
> proportion of people will, because it's easier to use than setuptools,
> *for builds*. But those people will then find that distributing their
> sources isn't something that flit covers, so they'll make up their own
> approach (if it were me, I'd probably just point people at the
> project's github account).
> 
> Once people get set up with a workflow that goes like this (build
> wheels and point people to github for source) it'll be harder to
> encourage them later to switch *back* to a process of uploading
> sources to PyPI.
> 
> And that I do think is bad - that we end up pushing people who would
> otherwise happily use PyPI for source and binary hosting, to end up
> with a solution where they host binaries only on PyPI and make the
> source available via another (non-standardised) means.

That's a fair argument indeed.

> In no way though am I proposing that we stop people making deliberate
> choices on how they distribute their packages. Just that we make
> hosting both source and binaries on PyPI the "no friction" easy option
> for (the majority of?) people who don't really mind, and just want to
> make their work publicly available.

Well, you know, there's an important difference between making
work publicly available and giving away the source code :-)

But I get your point and do support it: It should be possible
for package authors to use different build tools than distutils.

IMO, that's easy to achieve, though, with the existing de-facto
standard interface we already have: the setup.py command line API.
We'd just need to publish the minimal set of commands and options,
installer will want to see implemented in order to initiate
the builds.

> PS This has gone a long way off the topic of the build interface
> proposal, so I'm glad it's been spun off into its own thread. I'm now
> of the view that this relates at best peripherally to the build
> interface proposal, which I'll comment on in the other thread. 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Feb 10 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/