-
-
Notifications
You must be signed in to change notification settings - Fork 591
pip_compile: remove external/workspace_name prefix from generated requirements.txt #690
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
Conversation
The test is not added yet and I am expecting to break some existing ones. |
Friendly ping. |
I don't think this is really an improvement - these Can we just fixup the |
Sure. That makes sense. Just that's more work to do and I want to make sure
the upstream maintainer would think the issue is acceptable to be fixed
(which is not always the case) in the first place before I spend more time
on it.
Sent from https://boleyn.su/phone
…On Fri, Apr 22, 2022, 21:14 Alex Eagle ***@***.***> wrote:
I don't think this is really an improvement - these from lines are useful
documentation to say where a requirement came from, and the user doesn't
understand what stdin is in this case, it's hidden by Bazel.
Can we just fixup the external pathing before writing the file instead?
—
Reply to this email directly, view it on GitHub
<#690 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAXVSKBYKEZLSBJASDHHLQ3VGKQZVANCNFSM5TSQKVLQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
7d86772
to
34fb449
Compare
As a byproduct, this also allows |compile_pip_requirements| to comsume a generated requirements.in. |
@alexeagle Seems valid to me with proper tests. Anything else you want @BoleynSu to change? |
Yup, seems like a targeted fix. Even a simple test by checking in a requirements file that currently has an external/ segment would help. |
Cool. I will add some tests later. I have implemented something simliar to |
Hi @alexeagle and @f0rmiga, I have added the tests PTAL. Also I implemented something simliar to |
e1549e9
to
fc806a9
Compare
|
||
PIP_PACKAGES = {"sphinx": "4.5.0"} | ||
|
||
pip_deps( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this was the intent of the pip_parse_vendored
example introduced in 12662b6
could you just update that example instead of introducing another e2e test? They are kinda slow so it would be better not to accumulate more.
Also this doc 12662b6#diff-b92f94a67df862cde9714ff224afa676e39fe02da4fd4c6993daf684fbbc7cbdR182-R186 should maybe be updated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this was the intent of the
pip_parse_vendored
example introduced in 12662b6
The major issue with pip_parse_vendored and the approach used for golang is that the meta data is unknown to Bazel. With pip_deps, one can save all the metadata in a .bzl file so that the downstream can consume it, e.g., use it to resolve diamond dependency.
I did something similar with golang dependencies at https://github.com/BoleynSu-Org/monorepo/blob/main/configs/deps/go_deps.bzl.
could you just update that example instead of introducing another e2e test? They are kinda slow so it would be better not to accumulate more.
Sure, I think I can merge it into another e2e test.
Also this doc 12662b6#diff-b92f94a67df862cde9714ff224afa676e39fe02da4fd4c6993daf684fbbc7cbdR182-R186 should maybe be updated?
@@ -36,5 +36,6 @@ platforms: | |||
- "-//gazelle/..." | |||
# The dependencies needed for this test are not cross-platform: https://github.com/bazelbuild/rules_python/issues/260 | |||
- "-//tests:pip_repository_entry_points_example" | |||
- "-//tests:pip_deps_example" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why doesn't it work on Windows?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure. I guessed it was because bazel_integration_test
did not work well on Windows, which is likely wrong.
The error is caused by os.chdir("external\\unpinned_pip")
reporting no such directory. I do not have a Windows machine to debug it at the moment. Would you mind take a look if possible?
python_interpreter_target = None, | ||
**kwargs): | ||
_requirements_in( | ||
name = "unpinned_" + name, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the term "unpinned" may be inaccurate here. I'm not sure how it compares with rules_jvm_external, but here, the existing locked requirements file is still an input to pip-compile, so any already-pinned transitive dependencies will remain pinned to the same version. Only versions which no longer satisfy the constraints in requirements.in will actually change.
If the behavior is different from rules_jvm_external, then maybe another name would be better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the term "unpinned" may be inaccurate here. I'm not sure how it compares with rules_jvm_external, but here, the existing locked requirements file is still an input to pip-compile, so any already-pinned transitive dependencies will remain pinned to the same version. Only versions which no longer satisfy the constraints in requirements.in will actually change.
The input to _requirements_in
is packages
and output is a requirements.in
file. None of them have anything to do with the locked requirements file.
If the behavior is different from rules_jvm_external, then maybe another name would be better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a requirements_lock attribute here that gets passed to pip_compile. Am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. Yes, the locked requirements file is also part of the input.
It seems that [1] we can pass --upgrade
to achive this. It only read the locked file when there is no --upgrade
. I am also wondering why --upgrade
is not passed already? I think people are expecting this. We would better document it somewhere.
Also, in my usecase the requirements.txt is always generated so I did not ever notice it.
[1] https://github.com/jazzband/pip-tools/blob/master/piptools/scripts/compile.py#L352
Hi @alexeagle, I will remove |
Hi @alexeagle, I implemented another pip_deps at https://github.com/BoleynSu-Org/monorepo/blob/e819723afa334f5220097291969cd7c7bb419716/configs/deps/pip_deps.bzl which addressed this issue you pointed out. Thanks! Use site: Please let me know if you think this can be upstreamed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! sorry this got stalled for so long.
I'll get this in so that #689 can be fixed. |
…uirements.txt (bazel-contrib#690) * pip_compile: remove external/workspace_name prefix from generated requirements.txt * add some tests and a demo impl of pip_deps * update pinned requirement Co-authored-by: Alex Eagle <alex@aspect.dev>
Fixes #689
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: #689
What is the new behavior?
In the generated file
via -r filename
will be replaced withvia -r -
.Does this PR introduce a breaking change?
The existing generated tests will fail and a regeneration is required.
Other information