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

On Fri, Jul 7, 2017 at 12:59 AM, Thomas Kluyver wrote: > On Thu, Jul 6, 2017, at 11:51 PM, Paul Moore wrote: >> 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 >> backend's

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

On 7 July 2017 at 08:59, Thomas Kluyver wrote: > On Thu, Jul 6, 2017, at 11:51 PM, Paul Moore wrote: >> 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 >> backend's

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

On Thu, Jul 6, 2017, at 11:51 PM, Paul Moore wrote: > 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 > backend's responsibility to ensure reproducible isolated builds, I'd > be willing to listen. But

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

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

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

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

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

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,

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

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

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

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

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 >

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

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

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

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

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

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 >

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

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 >

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

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

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

On 6 July 2017 at 07:45, Nathaniel Smith wrote: > On Wed, Jul 5, 2017 at 9:14 AM, Thomas Kluyver wrote: >> On Wed, Jul 5, 2017, at 05:08 PM, Paul Moore wrote: >>> is that flit doesn't handle scenarios like "I unpacked a sdist" or "I >>> downloaded the

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

On Wed, Jul 5, 2017 at 9:14 AM, Thomas Kluyver wrote: > On Wed, Jul 5, 2017, at 05:08 PM, Paul Moore wrote: >> is that flit doesn't handle scenarios like "I unpacked a sdist" or "I >> downloaded the project archive from github and unpacked that" well. > > Flit handles these

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

On 5 July 2017 at 17:14, Thomas Kluyver wrote: > On Wed, Jul 5, 2017, at 05:08 PM, Paul Moore wrote: >> is that flit doesn't handle scenarios like "I unpacked a sdist" or "I >> downloaded the project archive from github and unpacked that" well. > > Flit handles these fine

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

On 2017-07-05 12:40:08 -0400 (-0400), Donald Stufft wrote: [...] > That doesn’t solve the “I downloaded a archive from GitHub” or “I > mounted my VCS checkout into a docker container without my VCS > installed”, but those can only be solved by the backend tool > itself and IMO it’s perfectly

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

> On Jul 5, 2017, at 12:08 PM, Paul Moore wrote: > > I have to say I still have deep reservations about flit's approach of > assuming/requiring that you're using VCS (git) to maintain your > project. I know that in practical terms most people will be, but it > still seems

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

On Wed, Jul 5, 2017, at 05:08 PM, Paul Moore wrote: > is that flit doesn't handle scenarios like "I unpacked a sdist" or "I > downloaded the project archive from github and unpacked that" well. Flit handles these fine for everything *apart* from making an sdist. It can make a wheel, install the

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

On 5 July 2017 at 16:19, Donald Stufft wrote: > Quite literally, the only case I can think of that fits into this is flit’s > “I will use git to figure out additional files, but you will have to > configure in a static file the name of the Python package (as in import > package)

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

> On Jul 5, 2017, at 11:19 AM, Donald Stufft wrote: > > The more I dig into this, the more I think Nathaniel is correct and we’re > trying to add a hook without any real world experience guiding it’s inclusion > that doesn’t actually solve the problem it’s trying to solve

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

> On Jul 5, 2017, at 2:02 AM, Nick Coghlan wrote: > > On 5 July 2017 at 15:49, Donald Stufft wrote: >> I’ve had a niggling feeling about this hook from the beginning, but I >> couldn’t quite put my finger on it until Nathaniel’s email made me realize >>

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

On 5 July 2017 at 15:49, Donald Stufft wrote: > I’ve had a niggling feeling about this hook from the beginning, but I > couldn’t quite put my finger on it until Nathaniel’s email made me realize > it. I feel like this hook is really *only* useful for flit, and for other >

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

> On Jul 4, 2017, at 11:53 PM, Nick Coghlan wrote: > > While it would definitely be useful to have a "check build > consistency" tool that built wheel files via all defined paths and > then used diffoscope to compare them, having such a tool available > wouldn't be a

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

On 5 July 2017 at 10:45, Nathaniel Smith wrote: > I already responded to several of the overall points elsewhere in the > thread, but a few specific points: > > On Mon, Jul 3, 2017 at 7:03 AM, Nick Coghlan wrote: >> I want prepare_wheel_metadata there as a

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

On 5 July 2017 at 03:24, Donald Stufft wrote: > It occurs to me that your case here is actually a reason *not* to implement > this hook. The goal of the hook is that the wheel built from the tree > created by copying this file is the same as the wheel built from a sdist >

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

I already responded to several of the overall points elsewhere in the thread, but a few specific points: On Mon, Jul 3, 2017 at 7:03 AM, Nick Coghlan wrote: > I want prepare_wheel_metadata there as a straightforward way for > backends to expose the equivalent of "setup.py

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

On Tue, Jul 4, 2017 at 11:03 AM, Donald Stufft wrote: > > I don’t think it’s (entirely) rehashing. The discussion has made me realize > that the purported cases covered by the hook aren’t actually going to be > covered except in a narrow set of circumstances, which suggests that

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

> On Jul 4, 2017, at 1:35 PM, Thomas Kluyver wrote: > > On Tue, Jul 4, 2017, at 06:24 PM, Donald Stufft wrote: >> It occurs to me that your case here is actually a reason *not* to implement >> this hook. The goal of the hook is that the wheel built from the tree >>

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

On Tue, Jul 4, 2017, at 06:24 PM, Donald Stufft wrote: > It occurs to me that your case here is actually a reason *not* to > implement this hook. The goal of the hook is that the wheel built from > the tree created by copying this file is the same as the wheel built > from a sdist created from

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

> On Jul 4, 2017, at 3:22 AM, Thomas Kluyver wrote: > > On Tue, Jul 4, 2017, at 01:06 AM, Donald Stufft wrote: >> 2) We have a VCS directory or “original development source” or whatever you >> want to call the thing you have before a sdist that typically gets into a >>

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

On 4 July 2017 at 18:58, Thomas Kluyver wrote: > On Tue, Jul 4, 2017, at 09:45 AM, Nick Coghlan wrote: >> +1, but we should explicitly note in the rationale section of the PEP >> that it's to cover both of the following cases: >> >> * build from an already unpacked and

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

On Tue, Jul 4, 2017, at 09:45 AM, Nick Coghlan wrote: > +1, but we should explicitly note in the rationale section of the PEP > that it's to cover both of the following cases: > > * build from an already unpacked and potentially edited sdist" > * cleanly support explicitly out-of-tree builds even

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

On 4 July 2017 at 17:22, Thomas Kluyver wrote: > On Tue, Jul 4, 2017, at 01:06 AM, Donald Stufft wrote: > > 2) We have a VCS directory or “original development source” or whatever you > want to call the thing you have before a sdist that typically gets into a > sdist. >

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

On 4 July 2017 at 08:22, Thomas Kluyver wrote: > Practical objection: besides it being a VCS checkout, you need the VCS tools > available (e.g. git on $PATH). It's not hard to imagine cases where this > doesn't hold, e.g. installing from a directory bind-mounted into a

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

On Tue, Jul 4, 2017, at 01:06 AM, Donald Stufft wrote: > 2) We have a VCS directory or “original development source” or >whatever you want to call the thing you have before a sdist that >typically gets into a sdist.> - Works on both proposals for setuptools > and flit (since both can

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

On 4 July 2017 at 12:46, Nathaniel Smith wrote: > if hasattr(os, "symlink"): > def prepare_build_files(tmp_dir): > os.symlink(os.getpwd(), tmp_dir) > > and now pip will do in-place builds. (Except on Windows, of course; > Windows users get screwed as usual, but from

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

On Mon, Jul 3, 2017 at 5:06 PM, Donald Stufft wrote: > Adding it on later is a bit tricky because we can’t pass the existing > metadata into the build_wheel hook then, so they can ensure that they > generate the same output. The frontend could still of course validate that >

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

> On Jul 3, 2017, at 10:03 AM, Nick Coghlan wrote: > > On 1 July 2017 at 20:53, Nathaniel Smith > wrote: >> Hi all, >> >> I just attempted an experimental refactor/streamlining of PEP 517, to >> match what I think it should look

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

-1 on _for_ ; why should a common prefix plus extra typing be any clearer than common suffix? Or rearrange the words without _for_. For the --config options, there's a double dash on the key and the value, I found that confusing. I suppose the theory, not thoroughly explained, is that the value

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

On 1 July 2017 at 20:53, Nathaniel Smith wrote: > Hi all, > > I just attempted an experimental refactor/streamlining of PEP 517, to > match what I think it should look like :-). I haven't submitted it as > a PR to the PEPs repository yet since I don't know if others will > agree

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

On 1 July 2017 at 11:53, Nathaniel Smith wrote: > I just attempted an experimental refactor/streamlining of PEP 517, to > match what I think it should look like :-). I haven't submitted it as > a PR to the PEPs repository yet since I don't know if others will > agree with the

<    1   2