On 10 June 2017 at 18:14, Nick Coghlan <ncogh...@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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
