On Tue, Jul 4, 2017, at 01:06 AM, Donald Stufft wrote:

2) We have a VCS directory or “original development source” or whatever you want to call the thing you have before a sdist that typically gets into a sdist.

- Works on both proposals for setuptools and flit (since both can go from a VCS to a sdist).

- Thomas might have said he’d be unhappy if this case goes through a real sdist… I forget the specifics of that discussion now.

Practical objection: besides it being a VCS checkout, you need the VCS tools available (e.g. git on $PATH). It's not hard to imagine cases where this doesn't hold, e.g. installing from a directory bind-mounted into a docker container. Between this and your case 3 (local directory not a VCS checkout), failures - while not common - won't be particularly rare.

Principle objection: you don't want an sdist! You want the necessary files copied efficiently to a clean location. You're using something complex as a proxy for something simple.

Prediction objection: If we end up with pip asking for an sdist when it's trying to build a wheel, I don't want to be endlessly explaining to people why it's broken. Nor do I want people to upload badly made sdists because flit doesn't have the necessary information to put extra files in there. Given the dominance of pip, I think my best option is to find a way for build_sdist to produce an sdist which pip accepts but pypi rejects if you try to upload it. I assume we all agree that's not optimal?

So can we please leave the hook in place?

(We could still avoid all of this if there was a way to trust the backend to build a wheel directly from the source directory, by the way.)

Thomas