On 4 June 2017 at 10:39, Ralf Gommers <ralf.gomm...@gmail.com> wrote: > > > On Sat, Jun 3, 2017 at 8:59 PM, Paul Moore <p.f.mo...@gmail.com> wrote: >> >> On 3 June 2017 at 03:14, Nathaniel Smith <n...@pobox.com> wrote: >> > So far my belief is that packages with expensive build processes are >> > going to ignore you and implement, ship, document, and recommend the >> > direct source-tree->wheel path for developer builds. You can force the >> > make-a-wheel-from-a-directory-without-copying-and-then-install-it >> > command have a name that doesn't start with "pip", but it's still >> > going to exist and be used. Why wouldn't it? It's trivial to implement >> > and it works, and I haven't heard any alternative proposals that have >> > either of those properties. [1] >> >> I may be misunderstanding you, but it's deeply concerning if you're >> saying "as a potential backend developer, I'm sitting here listening >> to the discussion about PEP 517 and I've decided not to raise my >> concerns but simply to let it be implemented and then ignore it". > > > I think you partly misunderstood - "ignore you" should mean "ignore pip" or > "ignore the mandatory sdist part of PEP 517" not "ignore all of PEP 517". > And concerns have been raised (just rejected as less important than the > possibility of more bug reports to pip)? > > And I agree with Nathaniel's view in the paragraph above. > >> >> OTOH, I'm not sure how you plan on ignoring it - are you suggesting >> that projects like numpy won't support "pip install numpy" except for >> wheel installs[1]? > > > Of course not, that will always be supported. It's just that where the > developer/build docs now say "python setup.py ..." we want them to say "pip > install . -v" and with sdist generation that won't happen - they will > instead say "somenewtool install ."
Allowing software consumption frontends like pip to completely replace setup.py as a *development* tool isn't one of the goals of PEP 517 - while we want to enable the use of both simpler (e.g flit) and more capable (e.g. Scons, meson, waf) alternatives without breaking end user installation processes and other tooling, it's also entirely acceptable for projects that are happy with setuptools/distutils as their build toolchain to keep using it. The subtitle of the packaging panel at PyCon US 2013 ended up being "'./setup.py install' must die", *not* "./setup.py must die" or "./setup.py sdist must die", and that focus specifically on software consumption wasn't an accident. Personally, I'm thoroughly opposed to commingling software publishing tasks and software consumption tasks in the same toolchain the way distutils/setuptools do (since you can't optimise for the needs of both software publishers *and* software consumers at the same time outside relatively narrow domains like the Chandler plugin system PJE originally wrote setuptools to handle), so I think the mismatched perspectives here may be due at least in part to my failing to communicate that adequately. When it appears otherwise, it's because I'm conceding that a "pip publish" front-end to a software publishing tool like twine may be beneficial for discoverability and learning purposes when folks are making the leap from "open source consumer" to "open source publisher", and because "retrieve & unpack sdist, apply downstream patches as needed, build & publish wheel" is a fairly common step in automated build pipelines that inherently blurs the line between software consumption and software publication :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
