The distutils build/ folder is what moves if you pass build_dir to the proposed function.
On Thu, Aug 24, 2017, 14:39 xoviat <xov...@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 <leoroch...@gmail.com> > : > >> >> 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 >> >> > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
