[Distutils] Provisionally accepting PEP 517's declarative build system interface

[Ralf Gommers]

> I think there's some pip bug somewhere discussing this ....

https://github.com/pypa/pip/issues/2195
https://github.com/pypa/pip/pull/3219
plus some long mailing list threads IIRC

On Mon, May 29, 2017 at 9:19 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 29 May 2017 at 08:05, Nathaniel Smith <njs at pobox.com> wrote:
> > Right now pip doesn't really have a good way to expressing the latter.

> 'pip install directory/' is relatively unambiguously saying that I
> > want a local install of some potentially-locally-modified files, and
> > while it might involve a temporary wheel internally there's no need to
> > expose this in any way (and e.g. it certainly shouldn't be cached), so
> > I think it's OK if this builds in-place and risks giving different
> > results than 'pip install sdist.tar.gz'. (Also note that in the most
> > common case where a naive user might use this accidentally, where
> > they've downloaded an sdist, unpacked it manually, and then run 'pip
> > install .', they *do* give the same results -- the potential for
> > trouble only comes when someone runs 'pip install .' multiple times in
> > the same directory.)
>
> I think that the key thing here is that as things stand, pip needs a
> means to copy an existing "source tree", as efficiently as possible.
> For local directories (source checkouts, typically) there's a lot of
> clutter that isn't needed to replicate the "source tree" aspect of the
> directory - but we can't reliably determine what is clutter and what
> isn't.
>
> Whether that copying is a good idea, in the face of the need to do
> incremental builds, is something of an open question - clearly we
> can't do something that closes the door on incremental builds, but
> equally the overhead of copying unwanted data is huge at the moment,
> and we can't ignore that.
>
> 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)

(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?

Ralf



>
> Paul
>
> [1] As pip is currently the only frontend, "what pip needs right now"
> is the only non-theoretical indication we have of what frontends might
> need to do, so we should be cautious about dismissing this as "pip
> shouldn't work like this", IMO.
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170529/ce7dc561/attachment.html>