On 24 August 2017 at 15:13, Thomas Kluyver <tho...@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 <tho...@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@python.org https://mail.python.org/mailman/listinfo/distutils-sig
