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
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
