feat: add alias generation for pip parse #814
Conversation
|
@corypaik would you be willing to rebase this PR? I think it's a very useful change! |
bfa2203 to
96efb1a
Compare
96efb1a to
db232db
Compare
Generate alias packages and targets for `pip_parse` under the parent repository. This serves two purposes. It allows for users to reference packages using a simpler `@pypi//package_name` without the import issues associated with putting the contents of the package there (as may be the case with `pip_install` following this naming pattern). Additionally, this allows users to override individual libraries either by default or based on select statements.
db232db to
d4ecd4c
Compare
|
Sorry, this fell off my radar. Can you explain more about the motivating use case a bit more? Essentially, you want to allow an arbitrary select condition to control what target is used? I'm not necessarily against doing so, but it strikes me as a bit strange -- ignoring Bazel for a moment, it'd be like pip installing something, then mucking with the install or sys.path to override particular libraries, which makes me raise my eye brows. Does pip have a builtin mechanism to ignore a particular dependency? Or maybe we should modify the requirements.txt processing to remove the desired library and replace it with the desired alias? There's a Bazel flag to override specific repositories -- does that satisfy the same need? Each pypi package being its own repo is most likely an intentional design decision (an unreferenced repo doesn't get loaded or fetched at all; I think it better isolates the repo-rule impact, too?). Putting everything into a single repo likely defeats that to some extent. I think the aliases need to be moved into the respective package's repo target -- this ensures that only a single actual target for a library is used. Otherwise, what you can do is e.g.
I think we deprecated pip_install in favor of pip_parse? I don't think we should add features to something we've deprecated. |
This is related to bazel-contrib#814 as it is bringing user-friendly alias generation and it is doing this in a breaking way for the `bzlmod` users who are not using the `requirement` macro. The labels that they use will change from `@@repo//:{name}_pkg` to `@@repo//{name}`. I am intentionally leaving the requirement macros in the requirements.bzl unchanged as bazel-contrib#989 might change the approach again. Since these aliases can be used by bzlmod and non-bzlmod users, we can then support the same generated `gazelle_python.yaml` for both bzlmod and non-bzlmod users.
|
This Pull Request has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days. |
|
This PR was automatically closed because it went 30 days without a reply since it was labeled "Can Close?" |
Generate alias packages and targets for
pip_parseunder the parent repository. This serves two purposes. It allows for users to reference packages using a simpler@pypi//package_namewithout the import issues associated with putting the contents of the package there (as may be the case withpip_installfollowing this naming pattern). Additionally, this allows users to override individual libraries either by default or based on select statements.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: N/A
Currently, in order to refer to a dependency by name with
pip_parseone must use the syntax@pypi_package_name//:pkg. It it also not currently possible to override the dependencies of pip repositories using local packages or those built with Bazel. The only workaround available now is to define a repository (e.g.,@pypi_package_nameprior to callingpip_parse. This is not ideal, and does not allow for selecting a version to use (e.g., local vs. from pip) via flags.What is the new behavior?
The alias packages add the option to refer to dependencies under one central repository using the syntax
@pypi//package_name. Additionally, it allows users to override the library targets by default or using any valid select statement.Note that the original names (e.g.,
@pypi_package_name//:pkg) remain unmodified, as do all functions inrequirements.bzl. The only exception is toall_requirements, which now uses the aliases instead. Happy to adjust this behavior as desired, my primary usage is@pypi//package_nameand a few interactive targets that useall_requirements.Does this PR introduce a breaking change?
Other information
I originally was working on a version which made the creation of alias packages optional (and disabled by default). After trying to profile both with and without the alias repositories I could not find any measurable difference so I got rid of the option entirely.
I've refactored the existing tests to work with these changes and added some notes to the
pip_parseexample, but I'd also be happy to add additional tests if need be.