On 5 July 2017 at 16:19, Donald Stufft <donald@stufft.io> wrote:
Quite literally, the only case I can think of that fits into this is flit’s “I will use git to figure out additional files, but you will have to configure in a static file the name of the Python package (as in import package) that you’re distributing and I’ll just glom down that entire package directory”. I know setuptools/distutils doesn’t work this way nor do any of the plugins that I am aware of. Best I can tell numpy.distutils nor enscons.
I have to say I still have deep reservations about flit's approach of assuming/requiring that you're using VCS (git) to maintain your project. I know that in practical terms most people will be, but it still seems like a strong assumption to make. One of the consequences is that flit doesn't handle scenarios like "I unpacked a sdist" or "I downloaded the project archive from github and unpacked that" well. And the result of *that* is that we're putting in mechanisms in the PEP to manage that approach. Having said that, I think flit is a great project, and I don't think that my personal dislike of one specific design choice is particularly relevant here. Also, I expect flit to be an important backend, simply because it makes it dirt-simple to package up a pure python project. So I do think that the flit use case is important for PEP 517. One thought - at the moment, all of the debate seems to be over the PEP side of things. That's not surprising, as distutils-sig is for debating standards, not tool design. But are there any changes that might make sense for flit that could improve things? For example, add some fallback mechanisms to flit that mean that it *can* always build a sdist, even if it has to make guesses in the absence of a VCS (if there's no VCS, include everything, or if there's no VCS, only include the minimum needed to build the wheel - both seem reasonable choices, and either seems better than "refuse to build a sdist"). Paul