Add support for relative 'file:' requirements in pip_install #367
Conversation
|
I'm not sure how you'd like to test this, since we'd require having a .whl file (or other supported requirement type) checked into the repo, perhaps in the Let me know what you'd like? |
|
Dnia sobota, 3 października 2020 15:21:29 CEST Adam Liddell pisze:
I'm not sure how you'd like to test this, since we'd require having a .whl
file (or other supported requirement type) checked into the repo, perhaps
in the `examples/pip_install` folder. We could either choose to find a very
small existing .whl file or create a tiny one ourselves. However, I can
understand hesitation towards adding another binary file, since the .par
files have been a pain to review in the past also.
Let me know what you'd like?
Can you use one of the wheels built in experimental/examples/wheel ?
…--
Paweł Stradomski
|
|
Unfortunately I don't think that can work easily, since the wheel has to exist at the time the repo rules are run. The wheel files created in that folder won't be present until much later when the execution phase has completed. Since they are technically separate workspaces, you could get it to work in CI by forcing the test order and copying the wheel at the right point, but it would not be a portable solution that would work for any contributors machine. |
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: closes #366
Relative
file:requirements do not work due topip wheelbeing run from the generated repository root.What is the new behavior?
Relative
file:URIs in requirements.txt are converted to absolutefile:///URIs based on the directory containing the requirements.txt file. This allows wheel files within the workspace to take part in dependency resolution, since the alternativewhl_libraryrule is both non-recommended and does not attempt to fetch dependencies based on the wheel metadata.Supports both
file:some/path/to/wheel.whlandrequirement @ file:some/path/to/wheel.whl. If a requirement is already absolute it will not be altered. For this to work, the requirements.txt file has to be copied into the generated repository, since we do not want to amend the source file in place.This does not attempt to support local wheels with paths specified without
file:, since these are equivalent but the bare requirement is harder to patch. Supporting that version consistently would require either writing a full parser for the requirements.txt format or depending on the internal implementation inpip._internal.Does this PR introduce a breaking change?
Other information
You may be able to deprecate
whl_libraryrule as a result of this, if desired.