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

[Donald Stufft]

> On Jun 10, 2017, at 1:31 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> 
> 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?

If they want to act as a standalone tool, they’re free to do that as well. This doesn’t require them to only support unpacked creation. They have a few options here, either they could implement their standalone path as simply consuming the same directory that twine would and just do a shutil.make_archive(…) on that directory OR they could just support a flag to switch their internal logic from copying to a target directory to building an in memory wheel. The file signatures are close enough that it should be pretty easy to do with functools.partial.


> 
> 
>> - 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.
> 

I think the best long thing here is to roll bdist_wheel into setuptools (it’s kind of silly we haven’t done this already since we’re standardizing on it now) and then have setuptools implement the PEP 517 interface.


—
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170610/d89a6ab1/attachment-0001.html>