[Distutils] abstract build system PEP update

[Donald Stufft]

> On Feb 17, 2016, at 6:20 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> 
> Currently, however, people using distutils can create sdists using
> "setup.py sdist". For other tools, this PEP does not specify how a
> sdist should be created, but it does imply that it is sufficient to
> make an archive of a source directory, including a "pypa.json" file,
> and pip will be able to consume that as a sdist. Whether tools provide
> a command to do this is out of scope for this PEP.


I'm writing my own alternative to this problem (was hoping to have it ready
yesterday, but I ended up with a migraine and spent most of the day MIA
instead) and it finally clicked to me why I felt that sdist needed to be a part
of this, and part of why I felt mildly uncomfortable by the PEP.

Right now, distutils/setuptools provides a number of functions:

* Installation from Sdist
* Building a Wheel
* Fetching Metadata
* Building a sdist
* Uploading

It's fair to say that I think we're trying to get away from the first of those
and it's a good thing that neither of these proposals include it. In addition
both proposals have fetching metadata and building wheels built into them.

Where they fall short is that there isn't a way to build a sdist or upload said
sdist to PyPI. The assumption is that people will just package up their local
directories and then publish them to PyPI. However I don't think that
assumption is reasonable.

You could say that using twine to handle the uploading is a thing people should
do (and I agree!) but that currently relies on having static metadata inside of
the sdist that twine can parse, static metadata that isn't going to exist if
you just simply tarball up a directory on disk.

So I think just tarballing up a directory on disk is *not* a reasonable way to
create a sdist, however you can't reasonably (IMO) create an independent tool
to handle this task with either of these build proposals either. For instance,
building a sdist requires getting the version of the project, that is going to
require some logic which is (in both of these PEPs) build system specific. So
taking flit for example, in order to build a sdist of a flit using package, a
tool is going to have to implement the same version detection logic that flit
itself is using (and the same goes for other metadata like name, and
long_description). As far as I can tell, any tool to create a sdist is going to
have to be specific to a particular build tool in order to have the same
metadata that you would get building a wheel.

The closest that either of these PEPs make it to being able to interrogate a
directory for the metadata is by asking it for the metadata that would occur
if we created a wheel file right now. While that is theortically enough
information, it's also going to contain things which do not belong in a sdist
at all.

In the end, I think *both* of the current proposals, as written, will cause
people to not uploads sdists because neither of them really address the fact
that their intent is to remove the standard interface for doing that, without
including a replacement to that interface.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160217/1c49c70f/attachment-0001.sig>