On Mon, Jul 10, 2017, 10:58 C Anthony Risinger <c...@anthonyrisinger.com> wrote:
> On Jul 10, 2017 8:59 AM, "Nick Coghlan" <ncogh...@gmail.com> wrote: > > On 10 July 2017 at 22:08, Jeremy Stanley <fu...@yuggoth.org> 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 were postponed to "build_wheel" now that we > >> have separate source and precompiled distribution formats. > > [...] > > > > This is a mildly naive view. The software I'm familiar with is > > actually attempting to reflect metadata _from_ the source revision > > control _into_ the sdist because while it's "tracked" there it's not > > tracked as normal files (version information from tags, change logs > > from the commit history, contributor lists from commit authorship). > > The metadata in question is lost by just blindly tarring up tracked > > files, so needs some mechanism to export and inject as untracked > > files (from the source revision control perspective) for inclusion > > in the sdist. > > Right, we know there will be *some* generated files (as Daniel notes, > there will typically at least be the metadata files in a > setuptools/distutils generated sdist), as well as potentially > modifications to some files based on the version history. > > 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 "build_directory" option to "build_sdist" as > well. > > And that's the part where we decided the answer is "No", we only want > to support the following configurations: > > build_sdist: > working directory -> target directory > > build_wheel: > working directory -> target directory > working directory -> build directory -> target directory > > In all cases the frontend provides a target directory that is distinct > from the current working directory, so backends have a place to put > both generated intermediate artifacts *and* the final assembled > archive file. > > > 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 > denominators for verification, reproducibility, and build simplicity, at > the expense of not being fully representative of the original build > capabilities and likely an irreversible step. > > I know there's been a lot of discussion here, and I probably missed it, > but early on we talked about things like Cython and cffi being part of > sdist generation (in setuptools at least). > > Are these things now expected to be deferred to the wheel building stage, > thus adding deps to the final build server, or are we just saying there is > less utility in supporting an explicit "artifacts directory" during sdist > generation? > Just that there is less utility in supporting a separate artifacts directory during sdist generation, correct. If the latter (and I think this is the case), that does seem reasonable, I > just wanted to confirm that such "compliations" are still expected, or at > least permissible, in downstream redistributables (sdists). > Personally if you want to do I want to help make it easier to do. -- > > C Anthony > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig