bazelbuild
Wrap reqs defined by `pip_parse.install_deps` in `maybe`
PR Checklist
Please check if your PR fulfills the following requirements:
- [ ] Tests for the changes have been added (for bug fixes / features)
- [ ] Docs have been added / updated (for bug fixes / features)
PR Type
What kind of change does this PR introduce?
- [ ] Bugfix
- [x] Feature (please, look at the "Scope of the project" section in the README.md file)
- [ ] Code style update (formatting, local variables)
- [ ] Refactoring (no functional changes, no api changes)
- [ ] Build related changes
- [ ] CI related changes
- [ ] Documentation content changes
- [ ] Other... Please describe:
What is the current behavior?
Currently with the new hermetic toolchains some packages don't work like they used to when using system python. A potential solution is to build custom wheels that do work with the new toolchain and explicitly define them as an http_archive. Unfortunately, the repository you get (to me) is ambiguous since there's no maybe wrapper around the whl_library repositories.
Issue Number: N/A
What is the new behavior?
This change wraps whl_library repositories defined by pip_parse in maybe to guarantee repositories with the same name defined first in the workspace get used.
Does this PR introduce a breaking change?
- [ ] Yes
- [x] No
Other information
I feel this kinda a stopgap, as in, if the http_archive should take precedence, then define it after the pip rule runs. Ideally we could provide a way to remove it from the lock file as I'm assuming it's only in there so pip can resolve dependencies for it?
Ideally there would only be 1 pip repository. But I think without something like https://github.com/bazelbuild/rules_python/issues/624 or guidance on how two different repos can coordinate a shared dependency pool based on what the root workspace is, this solves for confusion and allows users to maintain that "the repository defined first is what's used".