Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
15
contributors
Commits on Apr 24, 2023
-
fix: remove reference to @bazel_tools//tools/python/private:defs.bzl (#…
…1173) The file was removed in Bazel@HEAD in bazelbuild/bazel#17545 This fixes failures when using rules_python with Bazel@HEAD. Addresses: bazelbuild/bazel#17874
Commits on Apr 25, 2023
-
docs: Tell how to use GitHub to find commits in an upcoming release. (#…
…1092) I can never remember what the syntax is of the compare URLs, so just doc it to make it easier.
-
fix: compile_pip_requirements test from external repositories (#1124)
Previously when running the compile_pip_requirements test from an external repository the test failed. This was due to the fact that paths in the annotations of the lock file contained paths from the external repository. Another problem was that the requirement files could not be located.
Commits on Apr 26, 2023
-
test: Set mac platform for test_mac_requires_darwin_for_execution (#1179
) This makes the test pass on Bazel built from head. The failure appears due to not forcing the test to a Mac platform, so the underlying logic in `py_test` to detect the Mac platform fails and doesn't add the ExecutionInfo with the necessary info. Work towards bazelbuild/bazel/issues/18170
-
fix: Don't reference deleted private bazel_tools bzl file (#1180)
The latest versions of Bazel have removed the `@bazel_tools//tools/python:private/defs.bzl` file, so it can no longer be referenced. Work towards bazelbuild/bazel/issues/18170
Commits on Apr 27, 2023
-
docs: Add starlark directive to code snippet (#1170)
A very minor cleaup change.
-
tests: Upgrade rules_testing to 0.0.5 (#1184)
This just keeps it at a recent version, which makes errors easier to grok. rules_testing recently underwent a large refactor, so it's confusing when errors reference lines that no longer exist in recent versions.
Commits on Apr 28, 2023
-
tests: Set linux platform for test_non_mac_doesnt_require_darwin_for_…
…execution (#1183) This is the inverse test of the one testing for the mac platform. As before, the line forcing the platform to a non-mac platform was commented out, which meant, when a mac host built it, it would build the underlying target for Mac, which violated the test's assumptions. Work towards bazelbuild/bazel/issues/18170 Fixes #1185
Commits on May 1, 2023
-
fix(bzlmod): correctly template repository macros for requirements, e…
…tc (#1190) It seems that the macros for specifying the requirements break when the user starts using `incompatible_generate_aliases=True`. This PR fixes this. Testing done: 1. Modify the example: ``` $ git diff diff --git a/examples/bzlmod/MODULE.bazel b/examples/bzlmod/MODULE.bazel index ce91228..1750210 100644 --- a/examples/bzlmod/MODULE.bazel +++ b/examples/bzlmod/MODULE.bazel @@ -26,6 +26,7 @@ register_toolchains( pip = use_extension("@rules_python//python:extensions.bzl", "pip") pip.parse( name = "pip", + incompatible_generate_aliases=True, requirements_lock = "//:requirements_lock.txt", requirements_windows = "//:requirements_windows.txt", ) ``` 2. Run `bazel build ...` and check that it is still working. I noticed this when working on #1189 and creating a separate PR for easier cherry-picking if we wanted to make a patch release which includes this. I am not sure how I could make an automated test for this other than creating a separate example.
-
type:docs Update README.md (#1186)
Change instruction to refer to `MODULE.bazel` instead of `MODULES.bazel`.
Commits on May 2, 2023
-
fix: Allow passing a tuple to the
tagsattribute. (#1191)Starlark rules allow giving the tags as a tuple. The helper function that added the special migration tag assumed tags was always a list, resulting in an error when it tried to concatenate a list and tuple. To fix, check if tags is a tuple and concatenate a tuple if so. The input type of the tags attribute is preserved so that a test verifying tags can be passed to the underlying rule can be implemented (this test is to verify there isn't a regression during the rewrite to Starlark).
Commits on May 3, 2023
-
tests: Add skylib to various test dependencies to fix CI (#1199)
This fixes a problem where bazel skylib does not load during the toolchain integration test. The skylib dependency was introduced by #1191, but skylib was not present in the WORKSPACE configs of several things. To fix, skylib just needs to be added to the workspace files.
-
feat: removing bzlmod from example (#1200)
Having both bzlmod and a WORKSPACE file confuses the user, and I have #1155 which adds a new example for gazelle and bzlmod.
-
feat: propagate visibility attribute for py_wheel publishing (#1203)
py_wheel does not propagate "visibility" attribute to the "publish" rule. The visibility attribute on py_wheel target is not propagated to the auto-generated "publish" target. This commit adds the visibility attribute. Closes: #1192
-
-
tests: Force analysis test labels to resolve within @rules_python con…
…text (#1187) When a string label is passed to the `@rules_testing` analysis_test functions, the strings are evaluated within the context of @rules_testing because that is where the actual rule invocation happens. Without bzlmod, this just requires qualifying the labels with the repo name (which is what was being done) because there's just a flat global namespace of repos. With bzlmod enabled, repo mapping happens, so rules_testing tries to resolve those repo names using its repo mapping, which doesn't work because rules_testing's mapping doesn't include every repo using it.
Commits on May 4, 2023
-
fix(update_deleted_packages.sh): allow to run from anywhere in the re…
…po (#1206) It seems that the tool was correctly trying to modify the `.bazelrc` at the root of the repo, but the `find` execution would run in the `$PWD`. This change ensures that the `find` is consistent with the file we are trying to modify and allows the user to execute the script from anywhere in the repo. Tested: 1. Update the deleted packages with the version of the script at HEAD 1. Fix the bug 1. Rerun the script from the 'tests' sub-folder in the repo to ensure that running the script is noop. 1. Revert the changes to '.bazelrc' to reduce conflicts as other PRs are modifying it. Work towards #958.
-
feat(bzlmod): expose platform-agnostic repo target for toolchain inte…
…rpreter (#1155) This exposes a new repo and target, `@{name}_host_interpreter//:python`, created by `python.toolchain()`, that points to the host OS's Python interpreter for that particular toolchain. This solves two problems: 1. `pip.parse()` can now refer to the same interpreter used in the toolchains 2. There is now a canonical, public, way to refer to the host OS Python interpreter for repository rules. The above were _sort of_ possible for users to do already, but it required them to write much more configuration and extension code to do so. This moves that sort of boilerplate into our code so they have a simpler configuration. Also: - removing bzlmod support in the build_file_generation example; making examples work with both WORKSPACE and MODULE is a pain, hence splitting them. - adding an example of bzlmod and gazelle - improved documentation in the pip arguments Closes: #1161
-
fix(update_deleted_packages.sh): wheels example should not be include…
…d in .bazelrc (#1207) This correctly handles the integration tests and examples that are a part of the `rules_python` workspace and should not be included in the deleted packages list. This brings the changes made to the `.bazelrc` very close to what is in `main`, but I would like to update this later once #1155 and #1205 are merged. Fixes #919.
Commits on May 8, 2023
-
fix: Strip trailing newline from python output (#1212)
This is used to generate a path, which shouldn't have a trailing newline.
-
fix: manually ignore bazel-* directories to make using custom Bazel b…
…uilds easier (#1181) Normally, Bazel will ignore its convenience symlinks, so putting them in the .bazelignore file isn't necessary. However, when `--output_user_root` is set, which is beneficial to set when using different Bazel versions (it preserves the analysis cache between versions), the symlinks aren't ignored. Putting them in the bazelignore file fixes this.
Commits on May 14, 2023
-
test(bzlmod): explicitly enable bzlmod in the test harness (#1204)
Previously we would depend on the value of .bazelrc and this change ensures that we are explicitly enable bzlmod via CLI args. It seems that the `py_proto_library` integration tests defined in the `//examples:BUILD.bazel` file were not running using `bzlmod` before hand, however, they were correctly executed in the CI. Work towards #958.
Commits on May 15, 2023
-
feat(bzlmod): Cleaning up interpreter resolution (#1218)
This commit cleans up the use of "canonical resolution" of the Python interpreter. When the extension toolchains run it collects a list of the interpreters and then uses the hub_repo rule to create a map of names and the interpreter labels. Next, we then use the interpreter_extension that, creates reports that have symlinks pointing to the different interpreter binaries. The user can then pass in a label to the pip call for the specific hermetic interpreter.
-
feat(bzlmod)!: Move each bzlmod extension into its own file (#1226)
This commit refactors the files that contain the bzlmod extensions. - All extensions are moved under the new extensions folder - Private extensions are moved under extensions/private - All extension files are renamed to remove the _extension suffix - pip and internal_deps extensions are moved to their own file This commit organizes the extensions better and also follows the best practice of having a single extension per file. Having each extension in its own file allows them to use some additional features while helping avoid backwards incompatible changes. ## BREAKING CHANGES This splits `//python:extensions.bzl`, which previously held the `python` and `pip` extensions, into separate files (`python.bzl` and `pip.bzl`, respectively). Unfortunately, moving the location of the extensions is a breaking change due to how bzlmod extension identity works (see https://bazel.build/external/extension#extension_identity). Fortunately, by moving to one extension per file, we shouldn't have to ever do this again. Users must update the file path in their `use_repo()` statements as follows: * `use_extension("@rules_python//python:extensions.bzl", "python")` -> `use_extension("@rules_python//python/extensions:python.bzl", "python")` * `use_extension("@rules_python//python:extensions.bzl", "pip")` -> `use_extension("@rules_python//python/extensions:pip.bzl", "pip")` The following `sed` commands should approximate the necessary changes: ``` sed 'sXuse_extension("@rules_python//python:extensions.bzl", "python")Xuse_extension("@rules_python//python/extensions:python.bzl", "python")X'` sed 'sXuse_extension("@rules_python//python:extensions.bzl", "pip")Xuse_extension("@rules_python//python/extensions:pip.bzl", "pip")X'` ``` See `examples/bzlmod_build_file_generation/MODULE.bazel` for an example of the new paths.
-
Adding bzlmod support document (#1214)
This markdown file maintains the current status of our bzlmod implementation. Created section in README and linked to the bzlmod doc.
Commits on May 16, 2023
Commits on May 17, 2023
-
fix(toolchain): set correct return attrs to remove non-hermeticity wa…
…rning (#1231) Fixes the incorrect debug statement when downloading the toolchain for the first time asking users to replace "urls" with "url" in the toolchain definition which we maintain: ``` $ bazel build ... ... indicated that a canonical reproducible form can be obtained by modifying ... ``` Even though this is seen only once by the user, it may confuse them. Summary of changes: - refactor(toolchain): rename a local variable url -> urls - fix(toolchain): set url return attrs correctly
-
fix: allow url fragments in requirements file (#1195)
This commit addresses issue #1194 (see issue for details). It brings the `comment` detection of `requirements_parser.bzl` closer to the spec described here: - https://pip.pypa.io/en/stable/reference/requirements-file-format/#comments 1. Lines that begin with `#` are comments. 2. Content after (and including) ` #` is a comment. Prior to this commit, a dependency like this would result in invalid `pip wheel` arguments: ``` requests @ https://github.com/psf/requests/releases/download/v2.29.0/requests-2.29.0.tar.gz#sha1=3897c249b51a1a405d615a8c9cb92e5fdbf0dd49 ```
-
fix: Using canonical name in requirements.bzl (#1176)
When `incompatible_generate_aliases = False`, `pip.parse` doesn't work in bzlmod, because requirements.bzl has: ``` all_requirements = ["@rules_python~0.21.0~pip~pip_yapf//:pkg"] all_whl_requirements = ["@rules_python~0.21.0~pip~pip_yapf//:whl"] ``` Starting Bazel 6, canonical names should be referred with double "@". The reason why `incompatible_generate_aliases = True` worked is because it uses apparent name by parsing the canonical label with `repo_name = rctx.attr.name.split("~")[-1]`. This is dangerous because Bazel may change its canonical name pattern in future versions. This PR adds a new attribute "repo_name" to `pip_repository_bzlmod`, so we have access to the human-readable name in the implementation.
Commits on May 18, 2023
-
feat(bzlmod): support entry_point macro (#1220)
Add `entry_point` macro to the repo generated by the `pip.parse` extension. This works by using the canonical label literal, so should work without users needing to add the spoke repos to the `use_repo` statement. We test this by having an extra folder in the `bzlmod` example. Fixes #958.
There are no files selected for viewing