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

On 17 July 2017 at 23:06, Nathaniel Smith wrote: > On Mon, Jul 17, 2017 at 5:56 AM, Nick Coghlan wrote: >> As an added bonus: the frontend could display the exception message as >> part of executing the fallback. > > I can live with this, but I wrote up a

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

On 18 July 2017 at 01:25, Daniel Holth wrote: > Yes, build_directory does not do the same thing as sdist -> unpack -> build. > It would be more likely to be useful if you are not going through the sdist > step for any reason on a tree that has been built before. Ralf's

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

Yes, build_directory does not do the same thing as sdist -> unpack -> build. It would be more likely to be useful if you are not going through the sdist step for any reason on a tree that has been built before. The assumption being that the back end might use src/*.py as its source, but build/**

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

On Mon, Jul 17, 2017 at 6:36 AM, Daniel Holth wrote: > Here's my own summary. > > pip can do build_sdist -> unpack sdist -> build wheel if it wants to, > serving as some kind of linter if you happen to run 'pip install .' during > development. > > build_directory provides a way

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

On Mon, Jul 17, 2017 at 6:25 AM, Donald Stufft wrote: > Fwiw I also agree return values are more robust, though the fact that an > exception has a message is also a nice property since it allows backends to > provide a reason they dont support sdist in this tree (which some

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

Here's my own summary. pip can do build_sdist -> unpack sdist -> build wheel if it wants to, serving as some kind of linter if you happen to run 'pip install .' during development. build_directory provides a way to ask for a clean build, the lack of which causes problems in bdist_wheel

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

Fwiw I also agree return values are more robust, though the fact that an exception has a message is also a nice property since it allows backends to provide a reason they dont support sdist in this tree (which some tools may want to surface to users, particularly if they *need* a sdist, like a

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

On Mon, Jul 17, 2017, at 02:56 PM, Nick Coghlan wrote: > If Thomas is OK with it, I'd be fine with using "raise > NotImplementedError" for that purpose. I will implement this if it's what we decide, but I agree with Nathaniel that a sentinel value is probably more robust, because return values

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

On Mon, Jul 17, 2017 at 5:56 AM, Nick Coghlan wrote: > On 17 July 2017 at 22:48, Donald Stufft wrote: >> One point of issue with the PEP as it currently stands: I would greatly >> prefer it if we had a sigil to differentiate from "can't build the sdist, >>

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

On 17 July 2017 at 22:48, Donald Stufft wrote: > One point of issue with the PEP as it currently stands: I would greatly > prefer it if we had a sigil to differentiate from "can't build the sdist, > please fall back" from "an error has occurred trying to build the sdist". >

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

One point of issue with the PEP as it currently stands: I would greatly prefer it if we had a sigil to differentiate from "can't build the sdist, please fall back" from "an error has occurred trying to build the sdist". This would allow flit to return something that's says it can't build a

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

On 17 July 2017 at 22:19, Paul Moore wrote: > On 17 July 2017 at 13:04, Nick Coghlan wrote: >> While I do think it's still worthwhile to include the aspirational >> guidance around backends trying to keep their out-of-tree builds as >> close to the "build

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

On 17 July 2017 at 13:04, Nick Coghlan wrote: > While I do think it's still worthwhile to include the aspirational > guidance around backends trying to keep their out-of-tree builds as > close to the "build sdist -> unpack sdist -> build wheel" approach as > they can (as well

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

On 17 July 2017 at 21:30, Thomas Kluyver wrote: > On Mon, Jul 17, 2017, at 01:07 PM, Paul Moore wrote: >> If we have a consensus here that "build a sdist and build a wheel from >> it" is an acceptable/viable main route for pip to generate wheels >> (with "just ask the

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

On Mon, Jul 17, 2017 at 11:30 PM, Thomas Kluyver wrote: > On Mon, Jul 17, 2017, at 01:07 PM, Paul Moore wrote: > > If we have a consensus here that "build a sdist and build a wheel from > > it" is an acceptable/viable main route for pip to generate wheels > > (with "just

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

On Mon, Jul 17, 2017, at 01:07 PM, Paul Moore wrote: > If we have a consensus here that "build a sdist and build a wheel from > it" is an acceptable/viable main route for pip to generate wheels > (with "just ask the backend" as fallback) then I'm OK with not > bothering with an "ask the backend to

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

On 17 July 2017 at 11:41, Donald Stufft wrote: > FWIW I consider the idea of a try-extra-hard flag (either explicit in the > API or implicit in what kind of build you’re selected) a bad idea. While I > ultimately “lost” the fight to narrow down the “variants” of installs to VCS

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

On Mon, Jul 17, 2017 at 10:15 PM, Nick Coghlan wrote: > On 17 July 2017 at 20:00, Ralf Gommers wrote: > > > > > > On Mon, Jul 17, 2017 at 8:53 PM, Nick Coghlan > wrote: > >> > >> On 17 July 2017 at 18:29, Ralf Gommers

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

> On Jul 17, 2017, at 6:01 AM, Nick Coghlan wrote: > > And I can completely see the point of folks saying "But you're > conflating two different questions" when I declare the latter notion > redundant given out-of-tree build support, since that's exactly what > I'm doing:

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

On 17 July 2017 at 20:00, Ralf Gommers wrote: > > > On Mon, Jul 17, 2017 at 8:53 PM, Nick Coghlan wrote: >> >> On 17 July 2017 at 18:29, Ralf Gommers wrote: >> > On Mon, Jul 17, 2017 at 7:50 PM, Nick Coghlan

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

On 17 July 2017 at 18:53, Nick Coghlan wrote: > On 17 July 2017 at 18:29, Ralf Gommers wrote: >> On Mon, Jul 17, 2017 at 7:50 PM, Nick Coghlan wrote: >>> The minimal specification for in-place builds is "Whatever you would >>> do

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

On Mon, Jul 17, 2017 at 8:53 PM, Nick Coghlan wrote: > On 17 July 2017 at 18:29, Ralf Gommers wrote: > > On Mon, Jul 17, 2017 at 7:50 PM, Nick Coghlan > wrote: > >> The minimal specification for in-place builds is "Whatever you

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

On 17 July 2017 at 18:29, Ralf Gommers wrote: > On Mon, Jul 17, 2017 at 7:50 PM, Nick Coghlan wrote: >> The minimal specification for in-place builds is "Whatever you would >> do to build a wheel file from an unpacked sdist". > > Eh no, in-place has

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

On Mon, Jul 17, 2017 at 7:50 PM, Nick Coghlan wrote: > On 17 July 2017 at 15:41, Thomas Kluyver wrote: > > E) When we do work out the need and the semantics for in place builds, > > we can write another PEP adding an optional hook for that. > > The

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

On 17 July 2017 at 15:41, Thomas Kluyver wrote: > [I don't have time to properly read & respond now, but I wanted to > suggest something] > > Would it be better if we said that build_directory must always be > specified, i.e. passing None is invalid? > > A) Nathaniel has

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

Nathaniel Smith wrote: I think at the moment it's basically only you and me who actually have strong opinions, and everyone else is barely following. I've been a somewhat confused bystander in this thread for a while, and for what it's worth, I think Nathaniel is exactly right on these points:

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

On 16 July 2017 at 18:24, Nathaniel Smith wrote: > On Sat, Jul 15, 2017 at 11:27 PM, Nick Coghlan wrote: >> On 16 July 2017 at 14:56, Nathaniel Smith wrote: >>> But... that is not what the in-place/out-of-place distinction means in >>> normal

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

: distutils-sig Subject: Re: [Distutils] A possible refactor/streamlining of PEP 517 I agree that sdist consistency is not enforceable. Very little is. What if we deleted every unenforceable part of the PEP? No explanations of what backends should do. Every parameter is a hint. If you put the output

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

I agree that sdist consistency is not enforceable. Very little is. What if we deleted every unenforceable part of the PEP? No explanations of what backends should do. Every parameter is a hint. If you put the output file where requested then you are a good back end. Would that work better?

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

refactor/streamlining of PEP 517 On Sat, Jul 15, 2017 at 11:27 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 16 July 2017 at 14:56, Nathaniel Smith <n...@pobox.com> wrote: >> But... that is not what the in-place/out-of-place distinction means in >> normal usage, it's n

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

On Sat, Jul 15, 2017 at 11:27 PM, Nick Coghlan wrote: > On 16 July 2017 at 14:56, Nathaniel Smith wrote: >> But... that is not what the in-place/out-of-place distinction means in >> normal usage, it's not the distinction that any of those build systems >> you

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

On Sat, Jul 15, 2017, at 08:33 PM, Donald Stufft wrote: > I wonder if maybe it would be more useful to simply recommend that instead of > shelling out to random vcs binaries that these projects depend on (or bundle) > libraries to directly interact with a repository. For instance, if your >

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

> On Jul 15, 2017, at 11:50 PM, Nick Coghlan wrote: > > The exact norms around what's acceptable behaviour for out-of-tree > wheel builds (and just how hard backends should try to match the > build_sdist -> in-place build_wheel path in that case) is then > something that

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

On 16 July 2017 at 14:56, Nathaniel Smith wrote: > On Sat, Jul 15, 2017 at 8:50 PM, Nick Coghlan wrote: >> On 16 July 2017 at 04:33, Donald Stufft wrote: >>> All of that is a long winded way of saying I don’t particularly care if the >>> VCS

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

On 16 July 2017 at 04:33, Donald Stufft wrote: > [1] One note, I noticed there’s still instances of prepare_wheel_metadata in > the text. Good catch: https://github.com/python/peps/pull/311/files aims to deal with that through a combination of updating them to a new name, and

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

On Sat, Jul 15, 2017 at 8:50 PM, Nick Coghlan wrote: > On 16 July 2017 at 04:33, Donald Stufft wrote: >> All of that is a long winded way of saying I don’t particularly care if the >> VCS -> wheel -> install path is spelled out *always* doing in-place builds

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

On 16 July 2017 at 04:33, Donald Stufft wrote: > All of that is a long winded way of saying I don’t particularly care if the > VCS -> wheel -> install path is spelled out *always* doing in-place builds > or if we add a build directory to specify between out of place or in place.

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

> On Jul 15, 2017, at 6:54 AM, Paul Moore wrote: > > One particularly frustrating aspect of this discussion is that the > worst offender for "wheel and sdist are inconsistent" is the way that > setuptools requires developers to specify build and sdist contents > separately

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

On 16 July 2017 at 01:07, Nathaniel Smith wrote: > ...so this is where we diverge. As far as I understand it -- and I'm > pretty sure this matches all the major build systems like automake, > cmake, etc. -- the *only* difference between an in-place and > out-of-place build is

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

On 16 July 2017 at 00:15, Paul Moore wrote: > On 15 July 2017 at 14:06, Thomas Kluyver wrote: >> If those 'clutter' files are within the package directory (i.e. next to >> __init__.py), and we have to do a direct wheel build because VCS >> information

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

On Sat, Jul 15, 2017 at 3:54 AM, Paul Moore wrote: > On 15 July 2017 at 10:42, Nathaniel Smith wrote: >> Hi Paul, >> >> We seem to have some really fundamental miscommunication here; >> probably we should figure out what that is instead of continuing to >>

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

On 15 July 2017 at 14:06, Thomas Kluyver wrote: > If those 'clutter' files are within the package directory (i.e. next to > __init__.py), and we have to do a direct wheel build because VCS > information is not available (not a VCS checkout, or VCS not on PATH), > then I

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

On Sat, Jul 15, 2017, at 03:28 PM, Nick Coghlan wrote: > For flit, there are two main cases of interest: > > - publisher development environments > - building from release tarballs rather than VCS clones > > In the first case, the typical scenario will have both VCS metadata > *and* VCS tools

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

On 15 July 2017 at 23:06, Thomas Kluyver wrote: > So I don't see a good way to avoid picking up existing clutter when you > install from source. I think the main purpose of isolating the build is > to avoid generating new clutter in the source directory. Picking up clutter

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

On Sat, Jul 15, 2017, at 12:54 PM, Paul Moore wrote: > Given that this is the case we're talking > about, my experience is that working directories contain all sorts of > clutter - small test files I knocked up, experimental changes I > discarded, etc. That may simply reflect the way I work, but

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

On 15 July 2017 at 10:42, Nathaniel Smith wrote: > Hi Paul, > > We seem to have some really fundamental miscommunication here; > probably we should figure out what that is instead of continuing to > talk past each other. Agreed. Thanks for summarising your understanding. Let's

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

On 15 July 2017 at 19:42, Nathaniel Smith wrote: > Does that make sense? Does it... help explain any of the ways we're > talking past each other? I don't think you're talking past each other, I think you're explaining why Paul's preferred build strategy is for pip to always try

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

Hi Paul, We seem to have some really fundamental miscommunication here; probably we should figure out what that is instead of continuing to talk past each other. As a wild guess... can you define what an "out-of-place build" means to you? For me, the distinction between an in-place and

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

On 15 July 2017 at 18:45, Paul Moore wrote: > On 15 July 2017 at 09:16, Nathaniel Smith wrote: >> And then there's another thing called an "in place build", as opposed to an >> "out of place" build. In this case the distinction is just that an in-place >>

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

On 15 July 2017 at 09:16, Nathaniel Smith wrote: > There's one thing called an "in place build", like `setup.py build -i`, > where the idea is to convert the working source tree itself into something > you can put on your python path. It's related to doing "development" or >

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

On Jul 14, 2017 5:30 PM, "Ralf Gommers" wrote: On Sat, Jul 15, 2017 at 9:31 AM, Daniel Holth wrote: > I proposed the build directory parameter because the copytree hook made no > sense to me. It is not a perfect substitute but perhaps a configurable

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

On 15 July 2017 at 07:31, Daniel Holth wrote: > I proposed the build directory parameter because the copytree hook made no > sense to me. It is not a perfect substitute but perhaps a configurable build > directory is nice on its own without having to satisfy all older arguments

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

On Sat, Jul 15, 2017 at 9:31 AM, Daniel Holth wrote: > I proposed the build directory parameter because the copytree hook made no > sense to me. It is not a perfect substitute but perhaps a configurable > build directory is nice on its own without having to satisfy all older >

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

I proposed the build directory parameter because the copytree hook made no sense to me. It is not a perfect substitute but perhaps a configurable build directory is nice on its own without having to satisfy all older arguments in favor of copytree. I think true in-place builds are the oddball (for

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

On 14 July 2017 at 21:23, Donald Stufft wrote: > * I think it is a requirement that any PEP that proposes a mechanism for > removing ``setup.py`` supports sdist and wheel building in it’s interface. > Otherwise it sends a message that either one is an optional part of Python >

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

> On Jul 14, 2017, at 2:24 PM, Nathaniel Smith wrote: > > On Fri, Jul 14, 2017 at 4:00 AM, Nick Coghlan > wrote: >> On 14 July 2017 at 20:18, Nathaniel Smith wrote: >>> On Fri, Jul 7, 2017 at 8:27 PM, Nick

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

On Fri, Jul 14, 2017 at 4:00 AM, Nick Coghlan wrote: > On 14 July 2017 at 20:18, Nathaniel Smith wrote: >> On Fri, Jul 7, 2017 at 8:27 PM, Nick Coghlan wrote: >> Some possible problems that I've seen mentioned in the thread include: >> >>

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

> On Jul 14, 2017, at 9:46 AM, Thomas Kluyver wrote: > > On Fri, Jul 14, 2017, at 11:59 AM, Nathaniel Smith wrote: >> What are the advantages of this design, as compared to the >> fallback of doing unconditional copytree (like pip does now and may >> well continue doing

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

The PEP process is awful. Sorry. Thank you for helping to make this happen. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

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

On Fri, Jul 14, 2017, at 11:59 AM, Nathaniel Smith wrote: > What are the advantages of this design, as compared to the > fallback of doing unconditional copytree (like pip does now and may > well continue doing for years to come regardless of what we say here), I don't think pip currently does

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

On 14 July 2017 at 21:23, Nick Coghlan wrote: > The design that PEP 517 has settled on is to say that since both > in-place and out-of-tree builds are reasonable things for a frontend > to request, the *API* will allow frontends to request either an > in-place build

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

On 14 July 2017 at 20:59, Nathaniel Smith wrote: > On Fri, Jul 14, 2017 at 3:32 AM, Thomas Kluyver wrote: >> it appears to be non-negotiable that there is some >> way of building without affecting the source directory, so whatever the >> interface is, we

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

On 14 July 2017 at 11:32, Thomas Kluyver wrote: > On Fri, Jul 14, 2017, at 11:18 AM, Nathaniel Smith wrote: >> OTOH this whole 11th hour discussion of forcing every build system to >> have in-tree and out-of-tree build support is solving some other >> problem. > > It is not

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

On Fri, Jul 14, 2017 at 3:32 AM, Thomas Kluyver wrote: > it appears to be non-negotiable that there is some > way of building without affecting the source directory, so whatever the > interface is, we need some way to do this. But this is confusing the means with the ends.

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

On Fri, Jul 14, 2017, at 11:18 AM, Nathaniel Smith wrote: > OTOH this whole 11th hour discussion of forcing every build system to > have in-tree and out-of-tree build support is solving some other > problem. It is not my intention to force build systems to support either of these. - Where build

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

On Fri, Jul 7, 2017 at 8:27 PM, Nick Coghlan wrote: > The latest round of discussions have been enlightening, as they have > allowed us to articulate that from pip's point of view, the key > requirement is to be able to tell a backend not to include anything > that wouldn't be

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

On Tue, Jul 11, 2017, at 04:48 PM, Daniel Holth wrote: > Pro_duced. > > Mandatory backend hooks: > > - build_sdist(sdist_directory, config_settings={}) > - build_wheel(wheel_directory, config_settings={}, build_directory=None, > metadata_directory=None)> > Optional backend hooks: > > -

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

On Tue, Jul 11, 2017 at 9:58 AM Thomas Kluyver wrote: > To summarise the current state of this discussion as I understand it, > the hooks we are currently thinking of defining are: > > def get_build_wheel_requires(config_settings) > def

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

To summarise the current state of this discussion as I understand it, the hooks we are currently thinking of defining are: def get_build_wheel_requires(config_settings) def prepare_wheel_metadata(metadata_directory, config_settings) def build_wheel(wheel_directory, config_settings,

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

On 11 July 2017 at 06:56, Paul Moore wrote: > On 10 July 2017 at 21:28, Thomas Kluyver wrote: >> I don't think it's practical to forbid generating files to put in the >> sdist, but for pep517 I'd say it's appropriate to gently discourage it >> by not

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

On 10 July 2017 at 21:28, Thomas Kluyver wrote: > I don't think it's practical to forbid generating files to put in the > sdist, but for pep517 I'd say it's appropriate to gently discourage it > by not providing a build directory to that hook. I'm not going to argue > hard

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

On Mon, Jul 10, 2017, at 04:13 PM, Nick Coghlan wrote: > My apologies folks, this is an entirely irrelevant tangent brought on > by my attempting to explain my own preference that source archives > (including sdists) actually *be* source archives, containing solely > the original software is

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

On Mon, Jul 10, 2017, 10:58 C Anthony Risinger wrote: > On Jul 10, 2017 8:59 AM, "Nick Coghlan" wrote: > > On 10 July 2017 at 22:08, Jeremy Stanley wrote: > > On 2017-07-10 20:33:16 +1000 (+1000), Nick Coghlan wrote: > > [...] >

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

On 11 July 2017 at 00:58, C Anthony Risinger wrote: > When preparing a redistributable archive, we don't want people to first > generate difficult or inconvenient artifacts? I always thought that was a > major feature of an archive, to reduce the content down to common >

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

On Jul 10, 2017 8:59 AM, "Nick Coghlan" wrote: On 10 July 2017 at 22:08, Jeremy Stanley wrote: > On 2017-07-10 20:33:16 +1000 (+1000), Nick Coghlan wrote: > [...] >> we don't really *want* folks to be adding generated files to their >> sdist that they

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

On 11 July 2017 at 00:20, Paul Moore wrote: > On 10 July 2017 at 14:58, Nick Coghlan wrote: >> That isn't the question though - the question is whether we want to >> actively support folks moving "compilation" like activities >> (minification, pyx->C

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

A huge benefit to using non distutils build systems is making it easy to generate files at any step. I just don't think it's worth it to force a particular build directory at the generate sdist phase. Foolish consistentcy. On Mon, Jul 10, 2017, 10:20 Paul Moore wrote: > On

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

On 10 July 2017 at 14:58, Nick Coghlan wrote: > That isn't the question though - the question is whether we want to > actively support folks moving "compilation" like activities > (minification, pyx->C conversion, etc) to the sdist generation stage > by adding the optional

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

On 10 July 2017 at 22:08, Jeremy Stanley wrote: > On 2017-07-10 20:33:16 +1000 (+1000), Nick Coghlan wrote: > [...] >> we don't really *want* folks to be adding generated files to their >> sdist that they aren't keeping under source control - we'd prefer >> that such activities

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

Sdists contain generated PKG-INFO and .egg-info. I'd prefer to let the build backend manage any sdist build directory. It doesn't provide the same benefit to pip as the configurable wheel build directory. On Mon, Jul 10, 2017, 08:09 Jeremy Stanley wrote: > On 2017-07-10

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

On 2017-07-10 20:33:16 +1000 (+1000), Nick Coghlan wrote: [...] > we don't really *want* folks to be adding generated files to their > sdist that they aren't keeping under source control - we'd prefer > that such activities were postponed to "build_wheel" now that we > have separate source and

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

t; *Sent: *Monday, July 10, 2017 9:14 > *To: *distutils-sig@python.org > > > *Subject: *Re: [Distutils] A possible refactor/streamlining of PEP 517 > > > > On Mon, Jul 10, 2017, at 07:01 AM, Nick Coghlan wrote: > > > So I think we have pretty solid evidence that the reason t

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

On 10 July 2017 at 18:56, Ralf Gommers wrote: > On Mon, Jul 10, 2017 at 7:13 PM, Thomas Kluyver > wrote: >> >> On Mon, Jul 10, 2017, at 07:01 AM, Nick Coghlan wrote: >> > So I think we have pretty solid evidence that the reason the >> > procedural

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

On 10 July 2017 at 17:13, Thomas Kluyver wrote: > Do we want to also provide a build_directory for the build_sdist hook? > In principle, I don't think making an sdist should involve a build step, > but I know that some projects do perform steps like cython code gen or > JS

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

On Mon, Jul 10, 2017 at 7:13 PM, Thomas Kluyver wrote: > On Mon, Jul 10, 2017, at 07:01 AM, Nick Coghlan wrote: > > So I think we have pretty solid evidence that the reason the > > procedural "build directory preparation" hook wasn't sitting well with > > people was because

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

and backends should not blindly delete everything (or else they’ll get bug reports from very upset users). Cheers, Steve Top-posted from my Windows phone at EuroPython From: Thomas Kluyver Sent: Monday, July 10, 2017 9:14 To: distutils-sig@python.org Subject: Re: [Distutils] A possible refactor

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

On Mon, Jul 10, 2017, at 07:01 AM, Nick Coghlan wrote: > So I think we have pretty solid evidence that the reason the > procedural "build directory preparation" hook wasn't sitting well with > people was because that isn't the way build systems typically model > the concept, while a "build

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

On 8 July 2017 at 15:58, Nick Coghlan wrote: > Mostly assume in-place builds, no generic support for out-of-tree > builds that I can find, so developers of these shims will need to work > out how to handle "build_directory" (probably by copying the relevant > input files into

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

-plat support, so could potentially be useful on all platforms.) Cheers, Steve Top-posted from my Windows phone From: Nick Coghlan Sent: Saturday, July 8, 2017 7:59 To: Nathaniel Smith Cc: distutils-sig Subject: Re: [Distutils] A possible refactor/streamlining of PEP 517 On 8 July 2017 at 13:36

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

On 9 July 2017 at 01:17, Jeremy Kloth wrote: > On Fri, Jul 7, 2017 at 9:45 PM, Nick Coghlan wrote: >> On 7 July 2017 at 23:23, Daniel Holth wrote: >>> FYI distutils supports out of tree builds too. It is the -b argument to >>>

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

On Fri, Jul 7, 2017 at 9:45 PM, Nick Coghlan wrote: > On 7 July 2017 at 23:23, Daniel Holth wrote: >> FYI distutils supports out of tree builds too. It is the -b argument to >> 'setup.py build'. > > Sort of. That's short for "--bdist-dir" and tells

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

On 8 July 2017 at 13:36, Nathaniel Smith wrote: > On Fri, Jul 7, 2017 at 6:23 AM, Daniel Holth wrote: >> FYI distutils supports out of tree builds too. It is the -b argument to >> 'setup.py build'. > > In theory, yes, but in practice, there are lots of setup.py

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

On 7 July 2017 at 23:23, Daniel Holth wrote: > FYI distutils supports out of tree builds too. It is the -b argument to > 'setup.py build'. Sort of. That's short for "--bdist-dir" and tells distutils/setuptools not to use the "dist/" subdirectory for either build trees or the

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

On Fri, Jul 7, 2017 at 6:23 AM, Daniel Holth wrote: > FYI distutils supports out of tree builds too. It is the -b argument to > 'setup.py build'. In theory, yes, but in practice, there are lots of setup.py files out there that mutate the source directory. For example, every

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

On Fri, Jul 7, 2017 at 4:05 AM, Paul Moore wrote: > On 7 July 2017 at 11:30, Nathaniel Smith wrote: >> Is it absolutely necessary to get this into the first PEP? > > As far as I'm concerned, it's no more than a restating (and > simplification?) of all the

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

On 7 July 2017 at 20:30, Nathaniel Smith wrote: > I think this is a really interesting idea, but it makes me very > nervous that we're starting design work on novel features when we > still haven't finalized a basic build_wheel hook. This isn't a novel feature, it's a revised

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

On Fri, Jul 7, 2017 at 9:23 AM Daniel Holth wrote: > FYI distutils supports out of tree builds too. It is the -b argument to > 'setup.py build'. > And it works in bdist_wheel by adding half a dozen lines. It copies the -b argument to the 'build' subcommand, so effectively you

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

FYI distutils supports out of tree builds too. It is the -b argument to 'setup.py build'. On Fri, Jul 7, 2017 at 7:08 AM Paul Moore wrote: > Also, please note that the proposal doesn't *prohibit* in-place > builds, quite the opposite, it allows backends to decide when asked

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

Also, please note that the proposal doesn't *prohibit* in-place builds, quite the opposite, it allows backends to decide when asked how to implement both in-place and out of place builds (where the current tree allows backends to decide how to do in place builds and how to copy trees, and leaves

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

On 7 July 2017 at 11:30, Nathaniel Smith wrote: > Is it absolutely necessary to get this into the first PEP? As far as I'm concerned, it's no more than a restating (and simplification?) of all the discussions around building out of tree via creating an sdist and unpacking it, or

  1   2   >