On Aug 28, 2017, at 12:29 PM, Chris Barker <Chris.Barker@noaa.gov> wrote:

On Mon, Aug 28, 2017 at 9:21 AM, Donald Stufft <donald@stufft.io> wrote:
Donald, what do you think? IIRC, you were most keen on going
sdist->wheel where possible, and I don't think you've commented on
Paul's suggestion yet (apologies if I've overlooked a response).

I still think it should, and prefer pip to attempt to build a sdist prior to building a wheel when we’re coming from a VCS directory. I think that is going to be the most robust mechanism with the least amount of surprising behavior for end users.

why? even as it stands, doesn't setuptools dump everything into the build dir anyway? The "Creating of an sdist" really seems like a build-system problem, not a package manager problem to me.

> "when we’re coming from a VCS directory."

whether this is a VCS directory or some other source seems to me like something pip should not need to know...

Differences between what files are in a sdist and what files are in a VCS directory will lead to different behaviors on install which makes ``pip install .`` and ``build-a-sdist && pip install the-sdist.tar.gz`` behave differently. Attempting to funnel everything through the same VCS -> sdist -> wheel path makes it less likely for these kinds of issues to occur.

This is not a fully resolvable problem, and it is going to happen basically anytime you have two independent lists of what files get put into a sdist and what files get installed. It is not unique to setuptools nor is it a result of the way distutils/setuptools works— they only expose it more obviously because of their relevant APIs. Infact, both enscons and flit have this same problem (although flit has gone to some length to minimize the issue, so it’s somewhat hard, but not impossible, to actually trigger it).