Skip to content
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

Closed
jaraco opened this issue Dec 28, 2022 · 8 comments
Closed
Labels
enhancement New feature or request

Comments

@jaraco
Copy link
Member

jaraco commented Dec 28, 2022

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). The project_wheel_metadata call does allow for a isolated=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 probably build should do that instead. If, for example, the definition was project_wheel_metadata(isolated=get_bool_env('BUILD_ISOLATED', True)), then the downstream consumers could set BUILD_ISOLATED=false to disable isolated builds (and put the onus on them to supply the dependencies).

@FFY00 FFY00 added the enhancement New feature or request label Dec 28, 2022
@FFY00
Copy link
Member

FFY00 commented Dec 28, 2022

I think it can make sense, however, I think this should be something that the consumers have to explicitly opt into.

@nanonyme
Copy link

nanonyme commented Jan 6, 2023

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.

@nanonyme
Copy link

nanonyme commented Jan 6, 2023

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.

@layday
Copy link
Member

layday commented Jan 6, 2023

build doesn't support isolated offline builds at all. Offline implies no isolation.

@jaraco
Copy link
Member Author

jaraco commented Jul 30, 2023

See jaraco/jaraco.packaging#11 where an affected user contributed to jaraco.packaging to elicit an environment variable to override the behavior and avoid attempting to do a build while offline. Unfortunately, that patch was at the wrong layer, and it leaves other projects like jaraco/pytest-checkdocs#19 still failing in offline builds.

I'd really like for build to offer these users a way to provide pre-built wheels for load_metadata so to avoid building it.

If build doesn't want to offer this functionality, maybe I'll write a pytest plugin that monkeypatches build.load_metadata for all offline users.

@jaraco
Copy link
Member Author

jaraco commented Mar 31, 2024

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 PIP_FIND_LINKS and PIP_NO_INDEX. Indeed, it does:

 @ env PIP_NO_INDEX=1 PIP_FIND_LINKS=. pip-run -v tempora -- -c pass
Looking in links: .
Processing ./tempora-5.5.1-py3-none-any.whl
Processing ./pytz-2024.1-py2.py3-none-any.whl (from tempora)
Processing ./jaraco.functools-4.0.0-py3-none-any.whl (from tempora)
Processing ./more_itertools-10.2.0-py3-none-any.whl (from jaraco.functools>=1.20->tempora)
Installing collected packages: pytz, more-itertools, jaraco.functools, tempora
Successfully installed jaraco.functools-4.0.0 more-itertools-10.2.0 pytz-2024.1 tempora-5.5.1

(without PIP_FIND_LINKS, that command fails to find anything)

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.

I think it can make sense, however, I think this should be something that the consumers have to explicitly opt into.

That's right. The proposed behavior above is no change to the status quo, but allows offline builders to set BUILD_ISOLATED=False to opt out of the default isolation.

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.

Some builders already have the ability to cut network access completely, but that still doesn't help when build attempts to create an isolated environment and then doesn't have access to the network to resolve the dependencies declared by the build. If on the other hand, they've preemptively installed the dependencies into system site packages (or some other environment), which they've done, all they need to do is disable isolation and everything works.

build doesn't support isolated offline builds at all. Offline implies no isolation.

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 project_wheel_metadata to solicit its own environment variable and plumb it through to build.

PR incoming.

@jaraco jaraco self-assigned this Mar 31, 2024
jaraco added a commit to jaraco/build that referenced this issue Mar 31, 2024
…e environment, allowing builders to affect the isolation behavior. Closes pypa#556.
@jaraco
Copy link
Member Author

jaraco commented Mar 31, 2024

If build doesn't want to offer this functionality, maybe I'll write a pytest plugin that monkeypatches build.load_metadata for all offline users.

I realized a pytest plugin won't work, because jaraco.packaging is a sphinx plugin and pytest isn't relevant. It'd need to be its own package/library. Perhaps jaraco.packaging could actually provide this wrapper.

@jaraco jaraco removed their assignment Mar 31, 2024
jaraco added a commit to jaraco/jaraco.packaging that referenced this issue Mar 31, 2024
…port for a BUILD_ENVIRONMENT setting. Set BUILD_ENVIRONMENT=current to bypass isolation when loading metadata. Ref pypa/build#556.
jaraco added a commit to jaraco/jaraco.packaging that referenced this issue Mar 31, 2024
…port for a BUILD_ENVIRONMENT setting. Set BUILD_ENVIRONMENT=current to bypass isolation when loading metadata. Ref pypa/build#556.
jaraco added a commit to jaraco/pytest-checkdocs that referenced this issue Mar 31, 2024
@jaraco
Copy link
Member Author

jaraco commented Mar 31, 2024

This issue is addressed by jaraco.packaging >=9.5 in jaraco.packaging.metadata.load. Set BUILD_ENVIRONMENT=current and then invoke the tests/docs and the metadata will bypass the isolated build when loading metadata.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants