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

[Paul Moore]

On 10 June 2017 at 18:14, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Keeping it in the backend doesn’t really buy us much of anything, except
>> that a handful of backend authors don’t have to make relatively minor
>> adjustments to their code base. In a vacuum I can’t see any compelling
>> reason to have the backend do the archiving at all and the only reason I
>> think we’re talking about it is that’s just how the backends work now— but
>> again, changing that is almost certainly going to be extremely trivial to
>> do.
>
> Thanks for spelling those out - that's the intuition that prompted me
> to make the suggestion, but without working through the specifics I
> wasn't confident enough in the idea to specifically request that
> Thomas make the update.
>
> Thomas - I agree with Donald's reasoning here, so would you mind
> updating the PEP accordingly? I think it's OK if that means that the
> initial PEP 517 support in the existing backends builds the archive
> and then unpacks it:
>
> - future PEP 517 backends still won't need to include support for
> their own wheel building

Unless they want to act as standalone tools as well as backends - much
like flit does. I don't personally have a feel for how other backends
will look, will developers want to expose their own UI or will they be
happy to act just as a plugin to pip/twine/etc?

> - existing backends can do pack-and-unpack if that's easier for them,
> and defer refactoring until later
> - some backends may simply never be refactored, and that's between the
> backend developers and their users

Again, it's probably less of a refactoring, and more of a decision
about what UI (if any) they want to expose.

> - for setuptools, `bdist_wheel` is actually provided by Daniel Holth's
> wheel project, and that could potentially gain a
> `bdist_wheel_unpacked` command

One thing that we've never really discussed in any detail is what will
happen to setuptools in a post-PEP 517 world. At the moment, I'm sort
of working on the assumption that we'll simply have to retain the
existing setuptools support code until everyone's stopped using
setuptools. But the other option is that someone writes a backend that
wraps setuptools. Such a backend would rely on the
sdist/egg_info/bdist_wheel commands from setuptools and expose PEP 517
interfaces based on them. We could code pip to assume that backend if
there's no pyproject.toml, much like with the recent change to pip
that assumes setuptools is a build dependency unless there's a
pyproject.toml that explicitly states otherwise. But I don't know if
anyone is thinking of doing this.

Paul