Skip to content

Commit c369ec3

Browse files
authored
Merge branch 'main' into fix-pipstar-resolve-py-interpreter
2 parents 2d59623 + 1c8ca73 commit c369ec3

2 files changed

Lines changed: 50 additions & 6 deletions

File tree

README.md

Lines changed: 46 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,8 @@
66

77
This repository is the home of the core Python rules -- `py_library`,
88
`py_binary`, `py_test`, and related symbols that provide the basis for Python
9-
support in Bazel. It also contains package installation rules for integrating with PyPI and other indices.
9+
support in Bazel. It also contains package installation rules for integrating
10+
with PyPI and other indices.
1011

1112
Documentation for rules_python is at <https://rules-python.readthedocs.io> and in the
1213
[Bazel Build Encyclopedia](https://docs.bazel.build/versions/master/be/python.html).
@@ -17,7 +18,50 @@ The core rules are stable. Their implementation is subject to Bazel's
1718
[backward compatibility policy](https://docs.bazel.build/versions/master/backward-compatibility.html).
1819
This repository aims to follow [semantic versioning](https://semver.org).
1920

20-
The Bazel community maintains this repository. Neither Google nor the Bazel team provides support for the code. However, this repository is part of the test suite used to vet new Bazel releases. See [How to contribute](CONTRIBUTING.md) page for information on our development workflow.
21+
The Bazel community maintains this repository. Neither Google nor the Bazel team
22+
provides support for the code. However, this repository is part of the test
23+
suite used to vet new Bazel releases. See [How to contribute](CONTRIBUTING.md)
24+
page for information on our development workflow.
25+
26+
## Design
27+
28+
* Supported OSes - as per our supported platform policy, we strive for support
29+
on all of the platforms that we have CI for. Some platforms do not have the
30+
same backwards compatibility guarantees, but we hope the community can step in
31+
where needed to make the support more robust.
32+
* `requirements.txt` is how users have been defining dependencies for a long
33+
time. We support this to support legacy usecases or package managers that we
34+
don't support directly. Any additional information that we need will be
35+
retrieved from the SimpleAPI during the `bzlmod` extension evaluation phase.
36+
Then it will be written to the `MODULE.bazel.lock` file for future reuse. We
37+
have plans to support `uv.lock` file directly. `uv` is recommended for
38+
generating a fully locked `requirements.txt` file and we do provide a rule for
39+
it.
40+
* The `py_binary`, `py_test` rules should scale to large monorepos and we work
41+
hard to minimize the work done during analysis and build phase. What is more,
42+
the space requirements for should be minimal, so we strive to use symlinks
43+
rather than extracting wheels at build time. This means that for different
44+
configurations of the same build, we are not extracting the wheel multiple
45+
times thus scaling better over the time. From `2.0` onwards we are creating a
46+
virtual env for each target by creating an actual minimal virtual environment
47+
using symlinks. We plan on creating the traditional `site-packages` layout in
48+
the future by default.
49+
* Support for standards - we strive to first implement any standards needed
50+
within `rules_python` and this has resulted in a few PEPs supported within
51+
pure starlark - PEP440, PEP509.
52+
53+
Common misconceptions:
54+
* `rules_python` has to keep backwards compatibility with `google3`. Whilst this
55+
might have been true in the past, `rules_python` is an open source project and
56+
any compatibility needs should come from the community - we have no
57+
requirement to keep this compatibility and are allowed to make our decisions.
58+
However, we do want to keep backwards compatibility as long as possible to not
59+
upset users with never ending migrations.
60+
* `rules_python` is not caching pip downloads. With 2.0, we use Bazel's
61+
downloader by default and rely on bazel to provide the repository caching
62+
mechanisms. This means that for simpler setups this should result in
63+
transparent and scalable caching with the most recent bazel versions unless
64+
there are issues in the bazel itself.
2165

2266
## Documentation
2367

gazelle/WORKSPACE

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -26,10 +26,10 @@ http_archive(
2626

2727
http_archive(
2828
name = "bazel_gazelle",
29-
sha256 = "75df288c4b31c81eb50f51e2e14f4763cb7548daae126817247064637fd9ea62",
29+
sha256 = "675114d8b433d0a9f54d81171833be96ebc4113115664b791e6f204d58e93446",
3030
urls = [
31-
"https://mirror.bazel.build/github.com/bazelbuild/bazel-gazelle/releases/download/v0.36.0/bazel-gazelle-v0.36.0.tar.gz",
32-
"https://github.com/bazelbuild/bazel-gazelle/releases/download/v0.36.0/bazel-gazelle-v0.36.0.tar.gz",
31+
"https://mirror.bazel.build/github.com/bazelbuild/bazel-gazelle/releases/download/v0.47.0/bazel-gazelle-v0.47.0.tar.gz",
32+
"https://github.com/bazelbuild/bazel-gazelle/releases/download/v0.47.0/bazel-gazelle-v0.47.0.tar.gz",
3333
],
3434
)
3535

@@ -38,7 +38,7 @@ load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains", "go_rules_depe
3838

3939
go_rules_dependencies()
4040

41-
go_register_toolchains(version = "1.21.13")
41+
go_register_toolchains(version = "1.22.9")
4242

4343
gazelle_dependencies()
4444

0 commit comments

Comments
 (0)