You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This repository aims to follow [semantic versioning](https://semver.org).
19
20
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
0 commit comments