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

On Mon, Jul 10, 2017, 04:54 Steve Dower wrote: > One nice thing about providing a “put your work in this directory” setting > for all tasks is that only the front end has to know how and where to > create it, and how and when to clean it up later. Users may want to >

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

One nice thing about providing a “put your work in this directory” setting for all tasks is that only the front end has to know how and where to create it, and how and when to clean it up later. Users may want to configure this across all projects, regardless of the backend in use. Permitting

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