-
Notifications
You must be signed in to change notification settings - Fork 120
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
Solicit isolation setting from the environment. #766
Conversation
…e environment, allowing builders to affect the isolation behavior. Closes pypa#556.
I considered adding tests for this behavior, but decided against it, because it would require adding more dynamism to the behavior (processing the environment variable late) or otherwise refreshing the import of I'm a little worried about the choice of "BUILD_ENVIRONMENT" being a fairly general phrase and colliding with some other purpose. I'm aiming for |
This has the appearance of 'spooky action at a distance' - I'm not in favour of modifying library functions through environment variables, which take effect globally. An env var-controlled function can have multiple consumers stepping on each other's toes. In the original ticket, you say:
I think this is something that should in fact be done by the consumer and not by build. |
Since there is more than one consumer (at least pytest-checkdocs and jaraco.packaging), requiring the setting to be solicited by the consumer requires all of the consumers to coordinate or provide locally-unique settings. Do we really want This behavior doesn't feel that much more spooky than other environmental build flags like Even the consumers of this API don't have a great way to solicit this behavior, so they solicit it through environment variables. One is a sphinx plugin, the other a pytest plugin, so it's not obvious what direct method they could have to influence the behavior, and there's almost certainly no common solution across those two CLI surfaces (i.e. no argument you could pass to To my knowledge, these are just two consumers of this API, and these are possibly the only consumers of this API, and I do maintain both, so maybe I shouldn't be concerned about the coordination concerns, but my hope was to solicit the behavior where it's needed but make it reachable by the builders without having to plumb it through every consumer. At the very least, I'd like to consider adding a helper function that consumer could use thus: from build.util import project_wheel_metadata, infer_isolation
project_wheel_metadata(..., isolated=infer_isolation()) So that the logic behind the environment variable and inference could be consolidated. It still would require each consumer to opt into the inference, and it still would be spooky action at a distance, but I don't see a good alternative. In light of those concerns, does that shift your opinion at all? |
I'm pretty sure the test failures are unrelated to my changes. |
These env vars (are only advertised to) work with the pip CLI and not with its programmatic interface. I've no expectation that a hypothetical pip API would be parameterisable via env vars. It sounds like you're planning on invoking the build API in a subprocess (and are comparing it with pip as a result), but there's no reason why that should always be the case. I don't think |
It sounds like maybe there's no path forward with build. My next best solution is to provide this behavior through another library. As much trouble as it's been to contribute this functionality to pep517 and now to build, I'm conceding defeat. If build is refusing to address the concerns of downstream builders, we'll need yet another layer to address concerns. I guess I'll tackle the problem in jaraco.packaging. |
Closes #556.