> On Jun 10, 2017, at 1:31 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > > 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?
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
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
