[Distutils] Fwd: Re: PEP 517 again

[xoviat]

> It looks like a lot of trouble for a feature that is designed to solve a
problem for a very thin intersection of the Venn diagram of people who:

For the record, I don't agree at all that build_wheel_incremental should be
specified here. The suggestion is simply a compromise that I can tolerate
because it's optional.

> For better or worse, editable installs exist and don't need to be defined
by PEP 517 just to handle this case. I'm not convinced it's worth the
additional complexity of the spec just for that.

The editable installs in my opinion should have been specified in this PEP
because people are clearly trying to work around a lack of consensus on
that issue so that they don't have to wait for the next PEP and waste their
time waiting for uncached builds. I can't say I disagree with this but it's
trying to fit a square peg into a round hole.

> Is there any backend doing this "caching elsewhere" today? Is any backend
planning to?

Yes. Distutils caches in the build folder. It's very useful when working on
complex projects with Extensions.

> Can we arrive at some more concrete examples of how that would work? Like
how would pip be invoked, how would the backend react.

The reason that I'm willing to live with a separate optional function is
that I don't think it will ever be implemented. It will be a note in Python
history until install_editable is specified.

2017-08-24 13:30 GMT-05:00 Leonardo Rochael Almeida <leorochael at gmail.com>:

>
> On 24 August 2017 at 15:13, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
>
>> On Thu, Aug 24, 2017, at 06:20 PM, Daniel Holth wrote:
>>
>> On Thu, Aug 24, 2017 at 12:34 PM Thomas Kluyver <thomas at kluyver.me.uk>
>> wrote:
>>
>> Is there a reason to ask for an 'unclean' build, though? There may be a
>> performance optimisation from reusing cached data,
>>
>>
>> For the same reason you would ever ask for incremental builds, to more
>> quickly iterate while hacking, imagining that you are using the PEP 517
>> interface to develop, perhaps to have a uniform interface to patch
>> something when you are not familiar with exactly the build system it uses.
>>
>> It looks like a lot of trouble for a feature that is designed to solve a
> problem for a very thin intersection of the Venn diagram of people who:
>
>  a. wants to quickly iterate while hacking a package
>
>  b. doesn't want to bother learning how to trigger the incremental build
> system of that package or how to install it in editable mode.
>
> For better or worse, editable installs exist and don't need to be defined
> by PEP 517 just to handle this case. I'm not convinced it's worth the
> additional complexity of the spec just for that.
>
> Yup, this is what I meant about using cached data for performance. But I
>> don't think this requires builds to modify the source directory. The build
>> system can cache data elsewhere on the filesystem, whether or not it's
>> given an explicit build_directory.
>>
>
> Is there any backend doing this "caching elsewhere" today? Is any backend
> planning to?
>
>
>> I think we can specify one kind of build that is both 'clean' (doesn't
>> modify the source directory) and incremental (can use cached data to speed
>> up the build). If that's workable, it seems like it would save a lot of
>> headaches rather than trying to specify them as two different options.
>>
>> We have explicitly excluded editable installs (i.e. inplace builds) from
>> this PEP, though we can add a hook for that in a later PEP. I agree with
>> you that this PEP should allow for fast incremental (but non-inplace)
>> builds if possible, though.
>>
>
> Can we arrive at some more concrete examples of how that would work? Like
> how would pip be invoked, how would the backend react. And how (and for
> whom) this would be better than either doing an editable install or
> straight clean install?
>
> I fear we're complicating the spec for something that will be hard to
> happen in practice.
>
> _______________________________________________
> 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/20170824/33ef797e/attachment.html>