[Distutils] PEP 517: Open questions around artifact export directories

[Nick Coghlan]

On 10 June 2017 at 19:12, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> On Sat, Jun 10, 2017, at 04:32 AM, Nick Coghlan wrote:
>> 1. Move all artifact naming responsibilities to the frontend. All
>> backend hooks would just write files in the defined format into the
>> directory supplied by the frontend (and those directories would have
>> no defined naming scheme - they're just a staging area for the backend
>> to pass content to the frontend)
>
> If the 'make a wheel' hook needs to make an unpacked wheel, flit will
> probably implement this as building a wheel zip file, and then unpacking
> it into the target directory again. There isn't currently code for
> building an 'unpacked wheel', and I don't see any of this as performance
> criticial, since most users will be installing from a pre-built wheel
> anyway.
>
> This is OK if this is what we decide, but I wanted to highlight that at
> least in flit's case, there's no simplicity or performance benefit from
> asking for an unpacked wheel.

The fact this is also true for both "setup.py bdist_wheel" and for
"enscons" would then be the strongest argument in favour of keeping
the current "build_wheel" API: existing backends are already building
wheels for publication directly, so it makes sense to standardise on
what they're already doing, rather than requiring them to do extra
work just to support PEP 517.

We also expect even "build for installation" use cases to want the
wheel as an archive for caching purposes.

The rationale for `export_sdist_content` being inconsistent with that
would then be:

- the sdist naming and archive format isn't fully specified, so we
want to avoid depending on those details
- we specifically want `export_sdist_content` to be usable as a
fallback for `prepare_build_files` when backends don't define the
latter
- tools don't tend to cache locally generated sdists the way they do
wheel archives

That means the only suggested name changes would be:

- export_sdist -> export_sdist_content
- get_wheel_metadata -> prepare_wheel_metadata

The description of `build_wheel` would specifically mention the fact
that, unlikely the other hooks, it is the backend's responsibility to
actually generate the artifacts.


>> Assuming we add support for building multiple wheels from a single
>> source archive in the future, we'd do this through some kind of
>> declarative API based mechanism like adding a new optional
>> "wheel_name" parameter to `prepare_wheel_metadata` and
>> `export_wheel_content` (to tell the backend which wheel the frontend
>> is interested in), along with an additional field in [build-system] to
>> tell frontends which secondary wheels are defined by that project.
>
> This isn't really my area of expertise, but I would assume that we'd
> want to ask the backend to build all the wheels it knows about in one
> shot, not one-by-one.

Aye, that's how rpmbuild works, which would be another point in favour
of keeping the current `build_wheel` API.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia