[Distutils] Fwd: Re: PEP 517 again

[Daniel Holth]

The distutils build/ folder is what moves if you pass build_dir to the
proposed function.

On Thu, Aug 24, 2017, 14:39 xoviat <xoviat at gmail.com> wrote:

> > 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
>>
>>
> _______________________________________________
> 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/bdb60d84/attachment-0001.html>