Uh oh!
There was an error while loading. Please reload this page.
Allow for requirements files to differ per platform - #531
Conversation
82ebb17 to
956e1bfCompare956e1bf to
be0f661Compare232a6f3 to
8bf2bf4CompareAs a common example, we need a compiled requirements file for linux that differs from mac os
539cd04 to
f6c0e46CompareThe macros are leaky and otherwise you have to read sources to find out about the kwargs Fixesbazel-contrib#384
f6c0e46 to
0c811e0CompareThese are now natively supported by rules_python, cf. bazel-contrib/rules_python#531. This means we can now remove our hand-rolled support for per-platform requirements.
UebelAndre
commented
Apr 22, 2022
I think this is slightly incorrect. Instead of selecting the requirements based on the host, a dependency graph should be created for each target platform, so if I build on a macos host and target a linux platform (maybe for a docker container), I get the right set of requirements. Right now it'd be wrong unless my dependency graph happens to be the same. |
These are now natively supported by rules_python, cf. bazel-contrib/rules_python#531. This means we can now remove our hand-rolled support for per-platform requirements.
alexeagle
commented
Apr 23, 2022
@UebelAndre the actual install has to happen on the target platform so in a docker container you'd copy in the Linux requirements and use pip_install. There's no Mac outputs of pip_parse that can be useful there. |
alexeagle
commented
Aug 16, 2022
Note to self: this PR only updated the pip_parse/incremental=True codepath to use the platform-specific lockfile. |
As a common example, we need a compiled requirements file for linux that differs from mac os
PR Checklist
Please check if your PR fulfills the following requirements:
.parfiles. See CONTRIBUTING.md for infoPR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information