> On Feb 17, 2016, at 6:20 AM, Paul Moore <[email protected]> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
