[Distutils] PEP 517: Open questions around artifact export directories

[Donald Stufft]

> On Jun 15, 2017, at 5:05 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> 
> On 15 June 2017 at 21:49, Daniel Holth <dholth at gmail.com> wrote:
>> Nothing wrong with sdist of course, but one thing I hear from the emphasis
>> on sdist (something that pip can build automatically) is that maybe we are
>> worried that a publisher, who gave us the software for free, will unduly
>> inconvenience the consumer. But that would require an obligation from the
>> producer to the consumer that I don't think exists. The publisher can make
>> their software as useful or useless as possible, including not publishing it
>> at all. In practice many open source publishers through their own intrinsic
>> and mysterious motivations write and publish software that is both useful
>> and easy to consume. If they are not obligated to publish, how can they be
>> obligated to publish an sdist? even though they will likely do the latter in
>> most cases when doing the former.
> 
> The problem is not about obligation, so much as making the path that
> we want to promote the easiest.
> 
> Personally, I want to promote publication of sdists, as I believe
> publishing source is a key pillar of open source, and publishing it in
> a standardised, easy to consume form (not "go to my
> githib/bitbucket/google code page and work out how to download the
> source") is important. So, for me, making it as easy as possible for
> software authors to provide sdists is important - and therefore, I am
> in favour of requiring backends to provide a route to publish a sdist.
> Of course, it is perfectly OK for backend authors to *not* offer that
> facility, but again, I see no harm in making it easier for them to
> integrate if they do offer a "publish a sdist" route.
> 
> So my support for the sdist proposals is based on my personal beliefs
> around how to publish sources. Others may have different beliefs, and
> those beliefs may mean that they support or oppose my position.
> 
> But there's no requiring obligations here, just people supporting
> proposals that make things they care about easy, and (sometimes) make
> things they disagree with harder.
> 


While I agree publishers here are not being mandated or obligated to do anything (we don’t require they publish sdists *at all*, though we strongly encourage it) I want to push back against this idea that just because the publisher decided to release software for free means we can’t place any constraints on how they release that software. 

As a platform PyPI can and does impose constraints (for instance, you have to pick a version that fits with PEP 440 to upload to PyPI). If someone finds those constraints onerous they’re free to publish their software elsewhere or to agitate for a relaxation of those constraints. For each specific constraint we may or may not apply, we can argue the merits of that specific constraint and whether the benefits outweigh the burden, however the idea that we can’t impose constraints on an author is entirely absurd.

In the end we have just as much responsibility to the consumers of PyPI to ensure that they have a good ecosystem as we do to publishers to ensure we’re not unduly getting in their way. Sometimes that means applying a constraint to ensure some level of uniformity across PyPI other times that means giving authors power to manage their project as best makes sense for them.

—
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170615/9e435783/attachment.html>