This is relevant as I’m starting to figure out how to improve pip’s build logic and, hopefully, eventually move it out. A big part of the puzzle, is figuring out how we’d handle build environments. I’m aware that tox tried to use pep517, and gave up on it. pip isn’t 100% using pep517 either.
I’m considering this thread a place for a broader discussion about how we want to go about designing/working on the build environments library that works for the use cases where building with PEP 517 occurs.
@bernatgabor what were the pain points with pep517? How’s tox handling PEP 517 build environments right now?
@pf_moore@takluyver maybe y’all know why we haven’t moved code for isolation from pip to pep517? Is it just the lack of development time or was there a technical reason? It’s okay if you don’t know, I’m just not sure based on a quick skim of the two codebases and discussions in this area.
@pf_moore Responding here, since it’s OT for that thread.
It’s a bit of a catch 22 – you need the installer to be installed in the environment (i.e. pip today) or be capable of installing things in an environment specified to it. There’s no way to know which it is and so, putting the constraint of “tool is in charge of setting up environment when building with tool” is OK. Non-pip tools can use pip for the setup if they want to.
FWIW, I don’t disagree that having flexibility in build environment installers is a bad idea – I just don’t know how things would work in that model, and I’m keeping things simple for now, especially on that thread.
I did use “should” instead of “must” for exactly this reason there.
Good point. I was thinking at the low level, where I think the key point is that pep517 needs to let the caller specify the installer to use. In the normal case, this just means that pip asks it to use pip, and whatever other tool asks it to use that tool. Of course, then went on to over-generalise and think about tool A asking to use tool B, and it all got out of hand…
The biggest reason was simply limiting the amount of churn in the PR. I was having enough trouble not breaking stuff without doing a major refactor of the isolation code as well.
Beyond that, I recall the following factors that put me off using pep517 (does anyone else find it awkward distinguishing pep517-the-library and pep517-the-standard?):
Passing pip’s current set of options to the environment builder. Currently, pep517 punts on this and just calls pip. So things like proxy settings, extra index URLs, etc, may or may not get passed,depending on whether they are set in options or in environment variables/config files. Also, not all options are even appropriate for copying (should --platform be passed, for example?) I’m not even sure that pip gets all the edge cases right here, and I definitely didn’t want to try to copy that logic.
pep517’s code is simply less battle-tested. The isolation code in pip had been in use for a while, whereas to my knowledge, near enough no-one was using the pep517 library at the time we were adding PEP517 support to pip. For example, does pep517 handle forkbomb problems? (TBH, I can’t immediately find where pip handles these, but I know it was extensively discussed for pip).
I strongly believe that pep517 should be where everyone goes to do build isolation and PEP 517 style project builds. There’s simply no future in expecting every package management tool to write their own. But getting to that point is a significant chunk of work, and as usual, developer time is limited. That’s why I think that making use of pep517 (the library) a prerequisite for any new “pip/twine/??? build” command is important - we’ve ducked the issue once (or twice - I wasn’t aware tox had gone through the same exercise) and we need to avoid doing so again, or we’ll be going back to the old “pip is the reference implementation” situation, and stifling competition in the packaging space (in my ideal world, it should be possible to put together a very basic package installer by mostly just hooking together existing reusable parts - and it’s still way too hard to do that ).
@bernatgabor I think (and I’m sure others would agree) that it would be great for you to try proposing or sketching an API that might work or be closer to working for both your use case and the current use case it was coded for.
Maybe in half a year. I’m experimenting with an array of things trying to speed up as much as possible pep 517 packaging for tox. I don’t know what would be the ideal method but having to liason with a third party package I don’t control will probably significantly slow me down. Once I get it right and blazing fast I can circle back on this. For now trying to use pep517 the library gave me the impression that it focuses only on correctness, but I want more in tox 4. Swapping out parts of the library felt non trivial though, and also just reusing build environments that auto update on changes was something the library was not designed for.
For now I would consider that we should only consider pep517 the library as a implementation detail, and not try to make it the canonical builder. Any builder that implements PEP 517 is canonical in my eyes.
There is some code for isolation in pep517.envbuild, but as Paul mentioned, it’s not very battle tested. I kind of wrote it almost as an example: this is logically what setting up the build environment ought to involve. I didn’t think about things like the possibility of using indexes other than PyPI.
Note: I think the code in pep517.envbuild is fine for many situations (most people’s global pip config is in environment variables or config files anyway). TBH, I wish we could get away with simplifying pip rather than adding complexity to every other tool, but I don’t think we’ll ever be able to get away with that now
).