[Distutils] Fwd: Re: PEP 517 again
dholth at gmail.com
Thu Aug 24 14:58:52 EDT 2017
The distutils build/ folder is what moves if you pass build_dir to the
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>
>>> 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
> Distutils-SIG maillist - Distutils-SIG at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG