[Distutils] PEP: Build system abstraction for pip/conda etc

[Ralf Gommers]

On Thu, Feb 11, 2016 at 11:16 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 11 February 2016 at 17:50, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> > On Wed, Feb 10, 2016 at 2:43 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> >>
> >> On 10 February 2016 at 13:23, Nick Coghlan <ncoghlan at gmail.com> wrote:
> >> > On 10 February 2016 at 20:53, Paul Moore <p.f.moore at gmail.com> wrote:
> >> >> We don't have to solve the whole "sdist 2.0" issue right now. Simply
> >> >> saying that in order to publish pypa.json-based source trees you need
> >> >> to zip up the source directory, name the file "project-version.zip"
> >> >> and upload to PyPI, would be sufficient as a short-term answer
> >> >> (assuming that this *would* be a viable "source file" that pip could
> >> >> use - and I must be clear that I *haven't checked this*!!!)
> >
> >
> > This is exactly what pip itself does right now for "pip install .", so
> > clearly it is viable.
> >
> >> until
> >> >> something like Nathaniel's source distribution proposal, or a
> >> >> full-blown sdist-2.0 spec, is available. We'd need to support
> whatever
> >> >> stopgap proposal we recommend for backward compatibility in those new
> >> >> proposals, but that's a necessary cost of not wanting to delay the
> >> >> current PEP on those other ones.
> >> >
> >> > One of the reasons I went ahead and created the specifications page at
> >> > https://packaging.python.org/en/latest/specifications/ was to let us
> >> > tweak interoperability requirements as needed, without wasting
> >> > people's time with excessive PEP wrangling by requiring a separate PEP
> >> > for each interface affected by a proposal.
> >> >
> >> > In this case, the build system abstraction PEP should propose some
> >> > additional text for
> >> >
> >> >
> https://packaging.python.org/en/latest/specifications/#source-distribution-format
> >> > defining how to publish source archives containing a pypa.json file
> >> > and the setup.py shim.
> >
> >
> > The setup.py shim should be optional right? If a package author decides
> to
> > not care about older pip versions, then the shim isn't needed.
>
> Given how long it takes for new versions of pip to filter out through
> the ecosystem, the shim's going to be needed for quite a while. Since
> we have the power to make things "just work" even for folks on older
> pip versions that assume use of the setuptools/distutils CLI, it makes
> sense to nudge sdist creation tools in that direction.
>
> The real pay-off here is getting setup.py out of most source repos and
> replacing it with a declarative format - keeping it out of sdists is a
> non-goal from my perspective.
>

I don't feel too strongly about this, but:
- there's also a usability argument for no setup.py in sdists (people will
still unzip an sdist and run python setup.py install on it)
- it makes implementing something like 'flit sdist' more complicated;
without the shim it can be as simply as just zipping the non-hidden files
in the source tree.
- if flit decides not to implement sdist (good chance of that), then people
*will* still need to add the shim to their own source repos to comply to
this 'spec'.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160211/6a1c9213/attachment-0001.html>