Re: [Distutils] A possible refactor/streamlining of PEP 517

On Thu, Jul 6, 2017 at 3:09 AM, Robert Collins wrote: > On 1 July 2017 at 22:53, Nathaniel Smith wrote: >> Hi all, > >> If either hook is missing, or returns the built-in constant >> ``NotImplemented``. (Note that this is the object ``NotImplemented``, >> *not* the string ``"NotImplemented"`

Re: [Distutils] A possible refactor/streamlining of PEP 517

On 7 July 2017 at 07:54, Thomas Kluyver wrote: > On Thu, Jul 6, 2017, at 10:40 PM, Daniel Holth wrote: >> It might be more natural to pass a build directory for intermediate build >> artefacts along with the wheel output directory to the build wheel hook. >> This would remove pip from an awkward p

Re: [Distutils] A possible refactor/streamlining of PEP 517

On 6 July 2017 at 22:54, Thomas Kluyver wrote: > > I think Paul & Donald have been pretty adamantly against trusting backends > to build tidily, though On reflection, I'm less concerned about this than I was. If you wanted to propose a stripped down version of PEP 517 which assumed it was the bac

Re: [Distutils] A possible refactor/streamlining of PEP 517

On Thu, Jul 6, 2017, at 10:40 PM, Daniel Holth wrote: > It might be more natural to pass a build directory for intermediate build > artefacts along with the wheel output directory to the build wheel hook. This > would remove pip from an awkward position of managing a copy step in the > middle of

Re: [Distutils] A possible refactor/streamlining of PEP 517

It might be more natural to pass a build directory for intermediate build artefacts along with the wheel output directory to the build wheel hook. This would remove pip from an awkward position of managing a copy step in the middle of a build and would be more like out of tree builds in other build

Re: [Distutils] A possible refactor/streamlining of PEP 517

On Thu, Jul 6, 2017, at 07:19 PM, Paul Moore wrote: > That's a good point - and provides a good contrast to my perspective > as a pip developer that *pip* gets issues raised that aren't really > pip's problem. I think it's in everyone's best interests to ensure > that the user's experience is as un

Re: [Distutils] A possible refactor/streamlining of PEP 517

On 6 July 2017 at 17:35, Thomas Kluyver wrote: > Of course, I also have a vested interest in things not working this way: > I would get a steady trickle of people asking "why does flit require a > VCS to install from source?" From my perspective, it doesn't require > that, but I would be unable t

Re: [Distutils] A possible refactor/streamlining of PEP 517

On Thu, Jul 6, 2017, at 06:19 PM, Donald Stufft wrote: > I *think* if we had some way to signal expected failure vs unexpected failure > this would be reasonable to me. I wouldn’t just want it to flat out be any > failure, but if we used Nathaniels NotImplemented idea or something similar > to i

Re: [Distutils] A possible refactor/streamlining of PEP 517

> On Jul 6, 2017, at 12:35 PM, Thomas Kluyver wrote: > > Thanks Nick for the detailed reply. I have read it carefully, and you've > probably convinced me to get back on board. Some more responses inline: > > On Thu, Jul 6, 2017, at 03:38 PM, Nick Coghlan wrote: >> While I can completely underst

Re: [Distutils] A possible refactor/streamlining of PEP 517

Thanks Nick for the detailed reply. I have read it carefully, and you've probably convinced me to get back on board. Some more responses inline: On Thu, Jul 6, 2017, at 03:38 PM, Nick Coghlan wrote: > While I can completely understand how the current debate over whether > or not the prepare_input_

Re: [Distutils] A possible refactor/streamlining of PEP 517

> On Jul 6, 2017, at 11:36 AM, Paul Moore wrote: > > On 6 July 2017 at 15:54, Donald Stufft wrote: >> The fundamental problem here is that sdists *are* a key part of the build >> pipeline and are always going to be unless pip stops supporting sdists all >> together. I think it is a complete non

Re: [Distutils] A possible refactor/streamlining of PEP 517

On 6 July 2017 at 15:54, Donald Stufft wrote: > The fundamental problem here is that sdists *are* a key part of the build > pipeline and are always going to be unless pip stops supporting sdists all > together. I think it is a complete non-starter to suggest removing > installation from sdist supp

Re: [Distutils] A possible refactor/streamlining of PEP 517

> On Jul 6, 2017, at 10:38 AM, Nick Coghlan wrote: > > if you're not using > something like tox for your local testing, it's otherwise fairly easy > to inadvertently publish sdists that don't actually include all the > files they need to successfully build a wheel file Even if you *are* using

Re: [Distutils] A possible refactor/streamlining of PEP 517

> On Jul 6, 2017, at 6:26 AM, Ralf Gommers wrote: > > On Thu, Jul 6, 2017 at 8:57 PM, Thomas Kluyver > wrote: > Thank-you all for the discussion and the attempts to accommodate flit, > but I'll bow out now. It's become clear that the way flit approaches > packaging

Re: [Distutils] A possible refactor/streamlining of PEP 517

> On Jul 6, 2017, at 6:55 AM, Paul Moore wrote: > > On 6 July 2017 at 11:26, Ralf Gommers wrote: >> I hope you'll reconsider that deprecation - flit is one of only two (AFAIK) >> active attempts at making a saner build tool (enscons being the other one), >> and does have real value I think. >

Re: [Distutils] A possible refactor/streamlining of PEP 517

On 6 July 2017 at 18:57, Thomas Kluyver wrote: > Thank-you all for the discussion and the attempts to accommodate flit, > but I'll bow out now. It's become clear that the way flit approaches > packaging is fundamentally incompatible with the priorities other people > have for the ecosystem. While

Re: [Distutils] A possible refactor/streamlining of PEP 517

On Thu, Jul 6, 2017, at 11:55 AM, Paul Moore wrote: > On 6 July 2017 at 11:26, Ralf Gommers wrote: > > I hope you'll reconsider that deprecation - flit is one of only two (AFAIK) > > active attempts at making a saner build tool (enscons being the other one), > > and does have real value I think. >

Re: [Distutils] A possible refactor/streamlining of PEP 517

On Thu, Jul 6, 2017 at 10:57 AM, Thomas Kluyver wrote: > Thank-you all for the discussion and the attempts to accommodate flit, > but I'll bow out now. It's become clear that the way flit approaches > packaging is fundamentally incompatible with the priorities other people > have for the ecosystem

Re: [Distutils] A possible refactor/streamlining of PEP 517

On 6 July 2017 at 11:26, Ralf Gommers wrote: > I hope you'll reconsider that deprecation - flit is one of only two (AFAIK) > active attempts at making a saner build tool (enscons being the other one), > and does have real value I think. Agreed. In spite of the fact that I've been part of the push

Re: [Distutils] A possible refactor/streamlining of PEP 517

On Thu, Jul 6, 2017 at 8:57 PM, Thomas Kluyver wrote: > Thank-you all for the discussion and the attempts to accommodate flit, > but I'll bow out now. It's become clear that the way flit approaches > packaging is fundamentally incompatible with the priorities other people > have for the ecosystem

Re: [Distutils] A possible refactor/streamlining of PEP 517

On 1 July 2017 at 22:53, Nathaniel Smith wrote: > Hi all, > If either hook is missing, or returns the built-in constant > ``NotImplemented``. (Note that this is the object ``NotImplemented``, > *not* the string ``"NotImplemented"``), thank you for the clarification. I am unclear why you *re

Re: [Distutils] A possible refactor/streamlining of PEP 517

Thank-you all for the discussion and the attempts to accommodate flit, but I'll bow out now. It's become clear that the way flit approaches packaging is fundamentally incompatible with the priorities other people have for the ecosystem. Namely, I see sdists as archival artifacts to be made approxim