[Distutils] A possible refactor/streamlining of PEP 517

[Daniel Holth]

On Mon, Jul 10, 2017, 10:58 C Anthony Risinger <c at anthonyrisinger.com>
wrote:

> On Jul 10, 2017 8:59 AM, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
>
> On 10 July 2017 at 22:08, Jeremy Stanley <fungi at 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 at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170710/5a3ea605/attachment-0001.html>