Re: [Distutils] PEP 517 again

On Mon, Aug 28, 2017 at 12:50 PM, Paul Moore wrote: > Me too. At the moment, I only expect two backends of any substance - > your flit backend and xoviat's setuptools one. But I only know of one > frontend, namely pip - and talk of projects like tox or twine acting > as frontends never seems to g

Re: [Distutils] PEP 517 again

On Mon, Aug 28, 2017 at 12:20 PM, Paul Moore wrote: > > interface). So if pip calls build_sdist and then build_wheel, there will > be > > two source distributions built (one by pip and one by setuptools) before > > building a wheel. exactly why pip should NOT concern itself with the sdist -- ei

Re: [Distutils] PEP 517 again

On Mon, Aug 28, 2017 at 1:27 PM, Thomas Kluyver wrote: > On Mon, Aug 28, 2017, at 09:13 PM, Daniel Holth wrote: > > > Then end the debate by letting the PEP authors decide the return type, and > > write a paragraph explaining why the other options were rejected. It is not > > going to make a big d

Re: [Distutils] PEP 517 again

> If so, let the trumpets sound, and the heralds declare that "return NotImplemented" is the way to do it. (I hope I've remembered Nathaniel's preference right ;-) For better or for worse, the trumpets seem to be sounding against this idea (Nathaniel seemed okay with whatever Donald and Nick thoug

Re: [Distutils] PEP 517 again

On Mon, Aug 28, 2017, at 09:13 PM, Daniel Holth wrote: > Then end the debate by letting the PEP authors decide the return type, > and write a paragraph explaining why the other options were rejected. > It is not going to make a big difference. Will that work now? Are we all so tired of this endless

Re: [Distutils] PEP 517 again

> On Aug 28, 2017, at 3:59 PM, Thomas Kluyver wrote: > > The difference I see with the "return None" question is that there we > have an alternative (return NotImplemented) which is just as simple for > both sides, but avoids the identified issue with a buggy backend. The > only argument there s

Re: [Distutils] PBR/distutils2 with pep517 Support Was: Conditionless setup.py

On 2017-08-28 17:48:40 + (+), Daniel Holth wrote: > Imo PBR is entirely a setuptools creature, without special > concerns to operate in pep517 land. If I were them I'd rewrite it > to not require setup.py and call that pbr2. [...] While it's true that PBR relies on setuptools entrypoints _

Re: [Distutils] PEP 517 again

> On Aug 28, 2017, at 3:58 PM, Paul Moore wrote: > > On 28 August 2017 at 20:47, Donald Stufft wrote: >> I also believe it is fundamentally impossible for the backends to guarantee >> consistency if they have a separate list for what gets installed vs what >> gets put into a sdist without liter

Re: [Distutils] PEP 517 again

Then end the debate by letting the PEP authors decide the return type, and write a paragraph explaining why the other options were rejected. It is not going to make a big difference. On Mon, Aug 28, 2017 at 3:59 PM Thomas Kluyver wrote: > On Mon, Aug 28, 2017, at 08:50 PM, Paul Moore wrote: > >

Re: [Distutils] PEP 517 again

On Mon, Aug 28, 2017, at 08:50 PM, Paul Moore wrote: > My main motivation for wavering is that I thought agreeing to trust > the backend would simplify many of the decisions, and it's immensely > frustrating to me that we're still debating the same question in the > "return None" thread. The diffe

Re: [Distutils] PEP 517 again

On 28 August 2017 at 20:47, Donald Stufft wrote: > I also believe it is fundamentally impossible for the backends to guarantee > consistency if they have a separate list for what gets installed vs what > gets put into a sdist without literally building a sdist (or something > similar)— and as I un

Re: [Distutils] PEP 517 again

On Mon, Aug 28, 2017 at 3:48 PM xoviat wrote: > > But I'm suspicious of the rationale that *there will be fewer frontends so > they should have more responsibility*. > > To be fair, pip is currently struggling to keep up with project > requirements as it is, which has caused some frustration in t

Re: [Distutils] PEP 517 again

On 28 August 2017 at 20:32, Thomas Kluyver wrote: > On Mon, Aug 28, 2017, at 08:20 PM, Paul Moore wrote: >> Maybe we go fully to Nick's proposal that we don't mandate any sort of >> consistency constraints in the PEP. That would mean pip *has* to go >> sdist->wheel (because pip does need consisten

Re: [Distutils] PEP 517 again

> But I'm suspicious of the rationale that *there will be fewer frontends so they should have more responsibility*. To be fair, pip is currently struggling to keep up with project requirements as it is, which has caused some frustration in the community (not that the frustration isn't wrong, but I

Re: [Distutils] PEP 517 again

> On Aug 28, 2017, at 3:32 PM, Thomas Kluyver wrote: > > On Mon, Aug 28, 2017, at 08:20 PM, Paul Moore wrote: >> Maybe we go fully to Nick's proposal that we don't mandate any sort of >> consistency constraints in the PEP. That would mean pip *has* to go >> sdist->wheel (because pip does need co

Re: [Distutils] PEP 517 again

On Mon, Aug 28, 2017, at 08:20 PM, Paul Moore wrote: > Maybe we go fully to Nick's proposal that we don't mandate any sort of > consistency constraints in the PEP. That would mean pip *has* to go > sdist->wheel (because pip does need consistent behaviour), and > xoviat's setuptools backend can skip

Re: [Distutils] PEP 517 again

On 28 August 2017 at 19:50, xoviat wrote: > Personally, my plan for the setuptools backend will be to build a source > distribution (essentially using the command-line interface), extract into a > tmpdir, and then build a wheel (essentially using the command line > interface). So if pip calls buil

Re: [Distutils] PEP 517 again

On 28 August 2017 at 17:25, Chris Barker wrote: > Nor should it be for any other system. Before I saw this post I was about to > make a point about not contorting ourselves to make things works the same > way as pip and setuptools currently work -- pip was kind of hacked together > to support setu

Re: [Distutils] PEP 517 again

Personally, my plan for the setuptools backend will be to build a source distribution (essentially using the command-line interface), extract into a tmpdir, and then build a wheel (essentially using the command line interface). So if pip calls build_sdist and then build_wheel, there will be two sou

Re: [Distutils] PBR/distutils2 with pep517 Support Was: Conditionless setup.py

Imo PBR is entirely a setuptools creature, without special concerns to operate in pep517 land. If I were them I'd rewrite it to not require setup.py and call that pbr2. On Mon, Aug 28, 2017, 12:44 Chris Barker wrote: > I've thought for ages that we could transition to a more sane system by > co

Re: [Distutils] PEP 517 again

> On Aug 28, 2017, at 12:29 PM, Chris Barker wrote: > > On Mon, Aug 28, 2017 at 9:21 AM, Donald Stufft > wrote: >> Donald, what do you think? IIRC, you were most keen on going >> sdist->wheel where possible, and I don't think you've commented on >> Paul's suggestion yet

Re: [Distutils] PBR/distutils2 with pep517 Support Was: Conditionless setup.py

I've thought for ages that we could transition to a more sane system by convention: "your setup.py, after being imported, will have a "setup_params" attribute that is a dict that can be passed to setup()." So tools that want metadata, etc. without actually running an install could do; import se

Re: [Distutils] PEP 517 again

On Mon, Aug 28, 2017 at 9:21 AM, Donald Stufft wrote: > Donald, what do you think? IIRC, you were most keen on going > sdist->wheel where possible, and I don't think you've commented on > Paul's suggestion yet (apologies if I've overlooked a response). > > > I still think it should, and prefer pi

Re: [Distutils] PEP 517 again

On Sun, Aug 27, 2017 at 2:59 AM, Paul Moore wrote: > > Suppose you > > have a frontend like pip that when given a source directory and asked > > to build a wheel, wants to implement that as: > > - build sdist > > - unpack sdist > > - build wheel from unpacked sdist > > ... I'd like to > poi

Re: [Distutils] PEP 517 again

> On Aug 28, 2017, at 4:43 AM, Thomas Kluyver wrote: > > If pip does uses build_wheel directly, as Paul now prefers, I think we > can leave the NotImplemented/Error/None question for a later date. We > only want some way to signal "I can't do that" because a frontend might > try sdist->wheel wit

Re: [Distutils] PBR/distutils2 with pep517 Support Was: Conditionless setup.py

On 2017-08-28 13:05:07 +0200 (+0200), Thomas Güttler wrote: [...] > Are there PBR/distutils2 hackers on this list here? > > If yes: Do you support this pep? > > If no: where can you meet PBR/distutils2 hackers? See: https://mail.python.org/pipermail/distutils-sig/2017-August/031315.html -- Je

[Distutils] PBR/distutils2 with pep517 Support Was: Conditionless setup.py

Am 25.08.2017 um 15:00 schrieb Paul Moore: > > One thought - are the PBR and/or distutils2 teams looking at providing > PEP 517 support? Assuming they are, have they had a change to review > the PEP to ensure it suits their needs? And if they aren't, what is it > about the PEP that makes them unwi

Re: [Distutils] PEP 517 again

If pip does uses build_wheel directly, as Paul now prefers, I think we can leave the NotImplemented/Error/None question for a later date. We only want some way to signal "I can't do that" because a frontend might try sdist->wheel with a fallback to making a wheel directly. If no frontend is actuall