-
Notifications
You must be signed in to change notification settings - Fork 541
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
feat(bzlmod): support entry_point in bzlmod hub repos #1294
feat(bzlmod): support entry_point in bzlmod hub repos #1294
Conversation
4a8a2b5
to
a15a6e8
Compare
04584d4
to
6ad185b
Compare
It seems that that the CI failure might have been a flake. |
51baeb2
to
7cb90b2
Compare
This is ready for an initial review, I think. |
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.
Looks great overall. I love the tests! Some basic notes for you.
@rickeylev or another more senior person needs to look at the PR.
@aignas I have the test failing locally, but any ideas on how to debug the diff_test easier? Also, can you give me a breakdown of what your update script is doing? I can rewrite it in Powershell. |
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.
Can you post a pastebin of the generated BUILD files? Or otherwise describe them with some examples? It's hard to grok the overall build layout. I think I know what's going on, but an example would make sure we're on the same page. In a nutshell:
- The whl_alias repos are removed. It now goes piphub -> underlying pip package repos
- entry_point() is implemented by returning an inline select() expression
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 have refactored the code to use rules_testing
and in the process I needed to upgrade the version from 0.0.5
and add rules_license
to the internal dependencies. Overall the package is a great improvement over skylib
and the assertion output when the dictionaries do not match is great. The reason why I was using diff_test
is to actually workaround the limitations in ergonomics within skylib
.
@rickeylev, you are correct about the overall layout, the best is to checkout, run |
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.
Looking pretty good overall
tests/pip_hub_repository/render_pkg_aliases/render_pkg_aliases_test.bzl
Outdated
Show resolved
Hide resolved
tests/pip_hub_repository/render_pkg_aliases/render_pkg_aliases_test.bzl
Outdated
Show resolved
Hide resolved
tests/pip_hub_repository/render_pkg_aliases/render_pkg_aliases_test.bzl
Outdated
Show resolved
Hide resolved
tests/pip_hub_repository/render_pkg_aliases/render_pkg_aliases_test.bzl
Outdated
Show resolved
Hide resolved
I think a have a decent sense of the layout after looking at the render_pkg_aliases test -- that fairly nicely described the different build files, their content, and how they're referencing each other. |
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.
Just some naming and doc nits, otherwise lgtm.
Question -- what happens for the case where the available entry points differ? e.g. one has [foo], and the has [bar]? The resulting select expression would be e.g.
Is that going to work out OK? Or cause issues? I'm thinking of e.g. |
@rickeylev whilst looking at all this I've found a bug in the I think I would also like to make a PR for the I am not a huge fan of the |
3fd01c2
to
922905f
Compare
Before this PR there would be at least a few places where we would be converting a `X.Y.Z` version string to a shortened `X_Y` or `XY` string segment to be used in repository rule labels. This PR adds a small utility function that helps making things consistent. Work towards #1262, split from #1294.
922905f
to
683ebec
Compare
683ebec
to
1b88ae3
Compare
@@ -106,6 +109,9 @@ pip.parse( | |||
}, | |||
) | |||
pip.parse( | |||
entry_points = { |
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.
@rickeylev, instead of entry_point
macros, what do you think about the following extension API? You can see the bzlmod
example entry_point
test for how it works.
) Before this PR the only way to render aliases for PyPI package repos using the version-aware toolchain was to use the `whl_library_alias` repo. However, we have code that is creating aliases for packages within the hub repo and it is natural to merge the two approaches to keep the number of layers of indirection to minimum. - feat: support alias rendering for python aware toolchain targets. - refactor: use render_pkg_aliases everywhere. - refactor: move the function to a private `.bzl` file. - test: add unit tests for rendering of the aliases. Split from #1294 and work towards #1262 with ideas taken from #1320.
Introduce a new `entry_point` macro to `rules_python` as opposed to the `hub` repository which allows users to generate an `entry_point` script for a given package. This will check the `console_scripts` key in the `entry_points.txt` dist-info file and avoids eager fetching of third party repositories because it is a `genrule` and a `py_binary` underneath the hood and exists in `rules_python`. This is a breaking change for bzlmod users as they will have to start using `@rules_python//python:entry_point.bzl`. For others this new macro is available to be used, but the old code is still present. Fixes bazelbuild#1362 Fixes bazelbuild#543 Fixes bazelbuild#979 Fixes bazelbuild#1262 Closes bazelbuild#980 Closes bazelbuild#1294
Introduce a new `entry_point` macro to `rules_python` as opposed to the `hub` repository which allows users to generate an `entry_point` script for a given package. This will check the `console_scripts` key in the `entry_points.txt` dist-info file and avoids eager fetching of third party repositories because it is a `genrule` and a `py_binary` underneath the hood and exists in `rules_python`. This is a breaking change for bzlmod users as they will have to start using `@rules_python//python:entry_point.bzl`. For others this new macro is available to be used, but the old code is still present. Fixes bazelbuild#1362 Fixes bazelbuild#543 Fixes bazelbuild#979 Fixes bazelbuild#1262 Closes bazelbuild#980 Closes bazelbuild#1294
Introduce a new `entry_point` macro to `rules_python` as opposed to the `hub` repository which allows users to generate an `entry_point` script for a given package. This will check the `console_scripts` key in the `entry_points.txt` dist-info file and avoids eager fetching of third party repositories because it is a `genrule` and a `py_binary` underneath the hood and exists in `rules_python`. This is a breaking change for bzlmod users as they will have to start using `@rules_python//python:entry_point.bzl`. For others this new macro is available to be used, but the old code is still present. Fixes bazelbuild#1362 Fixes bazelbuild#543 Fixes bazelbuild#979 Fixes bazelbuild#1262 Closes bazelbuild#980 Closes bazelbuild#1294
#1363) Add `py_console_script_binary`, a macro/rule that allows better customization of how entry points are generated. Notable features of it are: * It allows passing in additional dependencies, which makes it easier for plugin dependencies to be added to tools such as pylint or sphinx. * The underlying `py_binary` rule can be passed in, allowing custom rules, such as the version-aware rules, to be used for the resulting binary. * Entry point generation is based upon a wheel's `entry_points.txt` file. This helps avoid loading external repositories unless they're actually used, allows entry points to have better version-aware support, and allows bzlmod to provide a supportable mechanism for entry points. Because the expected common use case is an entry point for our pip generated repos, there is special logic to make that easy and concisely do. Usage of `py_console_script_binary` is not tied to our pip code generation, though, and users can manually specify dependencies if they need to. BREAKING CHANGE: This is a breaking change, but only for bzlmod users. Note that bzlmod support is still beta. Bzlmod users will need to replace using `entry_point` from `requirements.bzl` with loading `py_console_script_binary` and defining the entry point locally: ``` load("@rules_python//python/entry_points:py_console_script_binary.bzl, "py_console_script_binary") py_console_script_binary(name="foo", pkg="@mypip//pylint") ``` For workspace users, this new macro is available to be used, but the old code is still present. Fixes #1362 Fixes #543 Fixes #979 Fixes #1262 Closes #980 Closes #1294 Closes #1055 --------- Co-authored-by: Richard Levasseur <[email protected]>
Before this PR users would need to get the Python version specific entry_point
which meant that the user may have issues when migrating from one default
version of Python to another. In this PR we:
generating docs.
external repositories we create.
entrypoints.bzl
file whilst initializing thewhl_library
whichcontains a dictionary of entrypoints available in this package.
entrypoints.bzl
file.entry_point
starlark macro, that is used from the hub repo macro.This makes the
bazel query @pip//...
fetch all of the targets, but this mightbe an acceptable price to pay given that there is now an easy way to query the
available entry_points in the hub repo.
Fixes #1262