-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Isolated builds when both pyproject.toml and setup.py co-exist #8437
Comments
Tagging the aforementioned maintainer of flake8 here in case they have anything to add to the discussion here. |
Hi, IIUC isolated build will get triggered when |
@McSinyx I do not want to speak on behalf of the flake8 maintainers but my understanding of their concern is that if My (unfounded, data here would be good) claim would be that users who have |
I think there's some misunderstanding here (either from my side or your side):
It is possible that you're confused about the meaning of build-isolation. If one's
perse should have the dependency specified in
are obsolete stuff build via e.g. GNU make and should be converted to or wrapped by Python tooling somehow. |
It's likely on my end. I've read the above-linked issue thread in the flake8 repo multiple times and I'm still not fully following. Maybe you can help me figure out what I am missing.
I think we both agree here. It's a long thread over there, but my understanding of the argument against supporting
Based on this:
I guess my question would then be, is the old pip build backend on deprecation track? If it is, there would be a stronger argument to suggest the "forced isolated builds" are not a concern since that would be the direction of the Python packaging ecosystem, and solutions are provided in the form of PEP 517/518. |
I agree with @McSinyx here. The example To demonstrate this, create a new virtualenv without six installed, and with just the given The fix for a project like this is to amend the documentation that says "you must manually install |
Title and top post edited to fix typos. I also removed #6163 from the title since it describes the use case of a |
To be 100% clear here, because I don't think anyone has clarified it — |
Also, this is not about Better documentation and blogs/articles/tutorials explaining how all of this hangs together would be very welcome. I don't know if anyone with the right combination of familiarity with the subject, good writing skills, and access to a suitable audience, would be able to help here. |
Hi @McSinyx @pfmoore @uranusjr and @pganssle thank you for taking the time to follow up on my question. I've been going back and forth with a flake8 developer via email (@asottile) based on your feedback. I asked if it was okay for me to share his concerns with this thread and he gave me the go-ahead. Here is an (abbreviated) summary of the exchange:
|
I'm not sure where this discussion is going. We've covered pip's existing behaviour. Is there a specific request for a change in pip that we can consider here? The current behaviour is a compromise (between encouraging projects to specify build dependencies in
are basically the two extremes that pip is compromising between. So which are you proposing we move to? Note that as far as I can see, there's been no explanation given of why a project that changes to add flake8 configuration to I'm genuinely baffled as to why people feel pip has to change, rather than projects make a simple build config update - so please, if there is a good reason, can someone explain it? |
Thank you all in this thread for pushing this discussion and development of pip forward. In regards to Black using This fix works with |
Probably a better fix would be to just explicitly add a Eventually the behavior that you are switching away from |
We will migrate to Thanks for following up about there being multiple paths, though, but we may peg |
We can close this issue now, right? There's nothing actionable, and it mainly seems like it's based on misunderstandings, which I'm not sure we can clarify better than we already have - both here and in many, many other venues. |
I would like to quote @pfmoore above:
This will get caught in testing, but it breaks existing behavior and leaves the developer with not much in terms of hints on where to turn. For example, we use
If I delete the I don't mind the change per se, I mind that the change is causing breaking behavior but that the developer is not provided a clear error message to prompt a migration. Edit: Since it's not listed explicitly, here would be a correct
|
As I already noted, better docs or other information is welcome. In particular, if anyone wants to submit a PR providing a better message covering this situation, it would be very much appreciated. However, I hope you understand that the pip developers aren't deliberately trying to obscure the issue here - the reason there's no such message at the moment is because it's hard to detect this situation, so anyone contemplating writing a PR should appreciate that. Anyway, as @pganssle noted, there isn't really anything actionable here, so I'm going to close the issue now. |
Fair enough, stay safe! |
Sorry for digging this topic up again, but I think this was closed prematurely and due to some misunderstanding. This issue is IMO still present, but it may be poorly described. So here is my (hopefully better) explanation: Currently there is no option to use
Why there may be need for package to have There may be some dependencies required for the package build that simply cannot be installed using pip (but such dependencies may be easily skipped for the runtime), to name a reason for a 2nd part of this question. The example above with six not being specified is quite misleading, as six can be installed by pip, so this is clearly an issue on the side of package maintainer by not providing proper build dependencies when doing so. A proper example should require a build dependency that is impossible to install using pip. Unfortunately, I cannot provide an example as this issue doesn't affect me personally, but I know some people affected by some python bindings for Mac OS API that has to be installed system-wide and cannot be installed inside a virtualenv. Unfortunately, I don't have any details for that, as I don't have a Mac OS environment to confirm that issue and any of people affected that I've asked to specify any details simply didn't provide those. As for the first part of that question above, there are some tools using |
There is not, because the plan is to make all (new) pip-installable projects to use PEP 517. The old non-
It’s perfectly fine for a project to not work with isolated builds. But if you need the project to be pip-installable, we expect it to be able to be built within an isolated environment going forward. Please raise the issues you have, so we can work on it. |
I understand that isolated builds will be mandatory at some point, but we are in the transition period right now and IMO this transition period should be done as smooth as possible. If there is a possibility to disable isolated builds by the end user, there should be one for package maintainers as well. Isolated builds are opt-in right now (implicit, by the existence of |
I fail to see how the transition isn't smooth. You test your library works in isolation builds (and other PEP 517 context), and once it does, you include |
As the scope of Also, as opt-in stage finishes, we shouldn't just force every package to use the isolated builds without any alternative to disable that project-wise, as not every package creators may get the memo that this switch is happening. Adding an I'm not saying that the opt-out should be permanently possible, but it should be for sure possible for some time after the opt-in phase |
It’s like upgrading to a new Python version. You either make your code compatibile and then switch to the new version, or you choose not to switch and don’t get the new features. You can’t have your cake and eat it too. |
I don't fully understand what you mean... As a package maintainer I have no control of which pip version the end user will use to install (and some cases also build my package, if for some reason I can't provide a wheel for his platform) my package. It's not a matter of not upgrading something on the package side when the switch in pip will happen to force build isolation on all packages. |
OK, I'm going to be blunt here, as far as I'm concerned (and yes, this is a personal opinion), tools that use If we ignore such tools for a moment, what @uranusjr says is quite correct - if your project isn't (yet) able to support build isolation, then you're not ready to opt into PEP 517/518 and you shouldn't have a So with that said, the only remaining issue is what if you want to use a tool that puts its config in Anyway, this issue is closed, so nothing is going to change as a result of any further discussion here. I hope the above explains things for you. |
According to the PEP 518, especially:
this is not an abuse, maybe it was in the future, but it is now allowed. That being said, we shouldn't simply ignore those tools in pip, because now we are abusing this file when making assumptions that specific package wants to use build isolation when this file exists. |
🤷 I said it was a personal opinion... Anyway, if we're trading PEP quotes, PEP 517 says
So pip is following the PEP recommendations. Honestly, I don't think this discussion is going anywhere, so I'll leave it here. |
i think the spec is pretty clear that having correct build metadata is not optional, and i like that it stays that way |
Spec is also pretty clear that isolated builds should be enabled regardless of the Right now, pip is slowing down the transition to the
I understand and accept that, but this is not what I'm disputing right now. If build isolation is an opt-in right now, it shouldn't be based on the presence of this file... Or there should be no opt-in at all. |
I think there's no appetite from pip's maintenance team to change the established method of opting-in to build isolation except in the direction of making more packages automatically use build isolation. @gbdlin It seems like you have a theoretical use case rather than a practical impediment here. Generally speaking, the advice here is:
Both of these are well-trodden ground, and it seems unlikely that pip is going to adopt an approach other than "try these workarounds if you have a problem." I am not sure that I can even come up with packages that cannot be pip installable without a little preparation. All that is required is to build wheels for them ahead of time and use either a local / caching PyPI server like devpi or even a wheelhouse (local directory as PyPI server). It is also possible to use the horribly-named and impossible to search for These approaches may not be convenient, but the standard here is "it should be possible", not "it should be easy". The majority of people shouldn't see any problems if they add a |
All I can really observe right now is that there are some tools that are postponing the migration to the
or equivalent. To not break any package that relies on isolated builds, this should default to false. It has additional benefits of making the transition period easier for some packages that are not aware of isolated builds being pushed forward and will wake up some day with being forced to use them which may require several hours of development to be possible. |
FWIW, one middle ground for pip is to not do build isolation if the pyproject.toml file doesn't contain a build-system table (this also means that those projects stay in a setuptools world, but that's likely OK). I've tried pushing for this before, but given the renewed interest here, floating that idea again. :) |
No build isolation, or no PEP 517 entirely? I think I'd be fine with the latter. (BTW can someone remind me which case is |
tl; dr Build isolation is unrelated to PEP 517. It's triggered by the "build via wheel" code path. There are at least 3 different "build via wheel" paths, all of which use isolation. A large history-lesson brain dump. To an extent just for the record, but also to give some context when we're debating what to do here. What the standards sayPEP 517 is actually pretty precise about how we should behave. The specification states that there are two source tree formats - legacy with In that section, the PEP says
So that again is entirely clear - if there's no So, to be clear, if there's a Build isolation is optional but recommended behaviour for conforming front ends, so we could choose not to do isolation. But pip has made the choice that we implement isolation for PEP 517, and I'm against changing that. Legacy behaviourOK, so let's look at the case where we hit "legacy behaviour". That's basically any case where there's no Some of this goes back 3 years, to when PEP 517 support was added (by me!) to pip. Other parts go back even further, to the PEP 518 support (which was not implemented by me). Build isolation was introduced with PEP 518, which is slightly odd, as PEP 518 makes no mention of build isolation, but without a "create a temporary build environment" mechanism, there's not much practical benefit to PEP 518. So isolated builds were introduced for all legacy builds, long before there even was an idea of a "legacy" build path. The only opt-out provided was Direct installsWhat does have an impact here is the even older ("legacy legacy", if you like 🙂) behaviour of installing directly with The thing is, if you are doing a direct install, build isolation is irrelevant, because we don't do a build! So anything that uses the direct-install code path doesn't use build isolation. This is (I believe) the code path that is being taken by projects that are complaining that adding Installing via wheelsPEP 517 has no mechanism for installing projects, only for building wheels. So anything that goes via PEP 517 must use install-via-wheel, simply because there's no alternative. Legacy builds may use install via wheel or direct install. The setuptools legacy PEP 517 backend, like any other PEP 517 backend, has no direct install mechanism, so that installs via wheel. The "direct All installs via wheel (by whatever mechanism) use build isolation, I believe. Which precise route used is complex, but basically down to judgement calls we made 3 years ago as to how fast we should push people towards PEP 517. This is where the mess of the Phew 😅 Note, by the way, that all of the logic here was implemented long before anyone suggested that using So where does that leave us?First of all, any requests to allow projects to not use build isolation are essentially requests to allow them to stick with the old, insecure, "run Secondly, this is stuff that has been present for three years, so it's not a new problem. What's new is people introducing I'm not claiming that decisions made 3 years ago can't be reviewed in the light of new fact. Nor am I even claiming that decisions I made at that time were necessarily the best ideas - a lot of what we decided was guesswork, frankly. But what I am saying is that every part of this behaviour is in code that we've been trying to deprecate and remove for at least 3 years, and probably longer. We're retaining the old behaviour because we don't have a good way of warning users that change is coming - so we have to make the transition extremely long. But "fixing" breakages where users have encountered the change and want some of the benefits but don't want to complete the work to switch, is deliberately extending the transition period, and does nothing to help us achieve the ultimate goal of removing all of that old code. OK, that's it. This post took me 3 hours to write, so I apologise if there are any remaining inaccuracies, but I have no more energy to go checking 💤 |
No build isolation introduces a brand new combination of conditions, that would need testing, would no doubt have weird interactions with other features, and would be yet another thing we'd eventually have to deprecate. It adds yet more complexity to the already-complex "legacy install" set of code paths. -1 from me. No PEP 517 (i.e., fall back to the If we have to do something like this, I'd argue for "no PEP 517 if there's no And of course when the "always build via wheel" changes are completed, there will be no |
Environment
Description
The maintainers of flake8 are suggesting that the adoption of
pyproject.toml
will not move forward until pip's behavior is amended. This seems to be due to the backend build system changing in the presence of apyproject.toml
file. Popular projects such as black have centralized their configuration usingpyproject.toml
and hence there may be many systems with bothsetup.py
and apyproject.toml
configuration files during the transition period topyproject.toml
for build specifications.I wanted to open a dialogue here to try and understand better understand pip's behavior in this regard and the maintainer's claim of "forced isolated builds with no recourse".
How to Reproduce
I was able to reproduce their issue with pip using the latest version.
The text was updated successfully, but these errors were encountered: