On 25 August 2017 at 06:54, Nick Coghlan <ncogh...@gmail.com> wrote: > On 25 August 2017 at 14:33, xoviat <xov...@gmail.com> wrote: >> Just this morning, Paul said the following: >> >> That step's the problem. If the frontend does that it can potentially >> be copying a lot of unneeded stuff (VCS history, for example). We >> tried that with pip and it was a major issue. That problem is the >> *whole point* of all the discussions about the various proposals that >> ended up with build_tree. >> >> I took that to mean that we were trusting the backend to do the right thing. >> And most people agreed with that. I don't personally care but there does >> seem to be some miscommunication here. > > Folks are wanting the "right thing" to be defined in the spec, but > that's the wrong place for it, since "the right thing" will be use > case dependent. So I'm now saying "stop trying to define what the > right thing is (beyond producing standards compliant artifacts), and > instead just define a usable thing, run with it, and let consensus on > 'the right thing' emerge over time".
I do believe that the PEP is the right place to make the point that *users* (not just front ends) have the right to expect that the direct wheel and sdist->wheel routes will produce the same results. Originally, I would have expected this to be self-evident, but with all the debates around incremental builds and similar, I now feel that it's necessary to clarify that this is the expected behaviour. Too many tools (not just pip, tox is another one) depend on the equivalence for us to leave it open to interpretation. If anyone feels that it's *not* reasonable for users to expect "build a wheel" and "build a sdist and build a wheel from that" to produce the same results for a given source tree (assuming the backend supports both building wheels and sdists from the given source tree) then they need to speak up with a *specific* example of a use case, so we can include it in the PEP as a motivating example, and use it in future debates. At the moment too much discussion is getting bogged down with comments like "I think someone said that XXX needs this..." I'm *not* interested in trying to tie down "the correct behaviour" any more tightly than this. > Donald and Paul originally didn't like that notion, but then Paul > realised that pip had never actually tried implementing the "always > build an sdist first" approach. That means pip's notion of "the right > thing" can be adequately captured as "source tree -> sdist -> wheel" > producing the same results as "source tree -> wheel", and pip can > strongly encourage that behaviour in backend implementations by always > trying build_sdist first, and only falling back to calling build_wheel > directly if build_sdist raises NotImplementedError. Precisely. Does any tool or participant in this discussion *not* see this as the minimal definition of correct behaviour, though? > Particular *frontends* (including pip) may further refine their > definition of the "right thing" to categorically disallow source tree > changes, but that's something they can do over time based on the bug > reports they actually receive, rather than needing to be mandated a > priori in the interface specification. I've never cared about whether the backend modifies the source tree, only that the direct-wheel / sdist->wheel equivalence holds. Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
