On 29 May 2017 at 11:46, Ralf Gommers <ralf.gomm...@gmail.com> wrote: >> Talking about a "build a sdist" operation brings a whole load of >> questions about whether there should be a sdist format, what about >> sdist 2.0, etc into the mix. So maybe we should avoid all that, and >> say that pip[1] needs a "copy a source tree" operation. Backends >> SHOULD implement that by skipping any unneeded files in the source >> tree,but can fall back to a simple copy if they wish. In fact, we >> could make the operation optional and have *pip* fall back to copying >> if necessary. It would then be a backend quality of implementation >> issue if builds are slow because multi-megabyte git trees get copied >> unnecessarily. > > > Doesn't that just move the problem from pip to backends? It's still a choice > between: > (1) making no copy (good for in-place builds and also fine for pbr & co, but > needs education or a "pip release" type command) > (2) making a full copy like now including .git, .vagrant, etc. (super > inefficient) > (3) making an efficient copy (will likely still break pbr and > setuptools-scm, *and* break in-place builds)
Yes, that's precisely what it does. The point being that a backend is the only code that can know what files are needed for the build, and which ones can safely not be copied. > >> (This operation might also help tools like setuptools-scm that need >> git information to work - the backend could extract that information >> on a "copy" operation and pit it somewhere static for the build). > > > If the backend can do it, so can pip right? No (see above). pip has to make the safe "copy everything" assumption, and that has a significant cost. Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
