-
Notifications
You must be signed in to change notification settings - Fork 121
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
Downstream packager unable to indicate "no isolation" for offline builds #556
Comments
I think it can make sense, however, I think this should be something that the consumers have to explicitly opt into. |
Seems like there's semantical clash here. Isolation (how pypa/build currently refers to it) is isolation from system packages. But this is isolation from download servers which is a different thing. (maybe we should use term offline rather than isolated?) So there probably should be separate switches. |
One way to handle this use case is simply cut network access completely from build sandbox so network requests fail but understandibly not everyone's build system supports that. |
build doesn't support isolated offline builds at all. Offline implies no isolation. |
See jaraco/jaraco.packaging#11 where an affected user contributed to I'd really like for build to offer these users a way to provide pre-built wheels for If |
One possible recommendation could be for these downstream consumers to keep build isolation and network isolation but to provide a server or directory of the dependencies (for an isolated build to succeed without network access). Perhaps that functionality already exists with
(without It's not obvious to me whether the use case is that they have wheels lying around for the dependencies or if they merely have the dependencies installed in some environment. If the dependencies are already installed somewhere and there are no wheels available, or if there's no installer (e.g. pip) available, then the build will still not succeed.
That's right. The proposed behavior above is no change to the status quo, but allows offline builders to set
Some builders already have the ability to cut network access completely, but that still doesn't help when
The corelary is that "no isolation" enables offline. Hence I want to give users the ability to disable isolation without requiring every library that uses PR incoming. |
…e environment, allowing builders to affect the isolation behavior. Closes pypa#556.
I realized a pytest plugin won't work, because |
…port for a BUILD_ENVIRONMENT setting. Set BUILD_ENVIRONMENT=current to bypass isolation when loading metadata. Ref pypa/build#556.
…port for a BUILD_ENVIRONMENT setting. Set BUILD_ENVIRONMENT=current to bypass isolation when loading metadata. Ref pypa/build#556.
This issue is addressed by jaraco.packaging >=9.5 in |
In jaraco/jaraco.packaging#7 and jaraco/jaraco.packaging#9 and jaraco/jaraco.packaging#10, downstream packagers are struggling with the isolated builds as created by
build.utils.project_wheel_metadata
. These packagers would like to perform offline builds (preventing access to the network for resolving dependencies). Theproject_wheel_metadata
call does allow for aisolated=False
, but in the case where it's being enacted programmatically, the downstream user doesn't have any control.I could imagine that each consumer of
project_wheel_metadata
could expose an environment variable or other configuration mechanism to alter the behavior, but probablybuild
should do that instead. If, for example, the definition wasproject_wheel_metadata(isolated=get_bool_env('BUILD_ISOLATED', True))
, then the downstream consumers could setBUILD_ISOLATED=false
to disable isolated builds (and put the onus on them to supply the dependencies).The text was updated successfully, but these errors were encountered: