Before this PR the `uv` toolchain could not be used in a `genrule` it
seems because the `//python/uv:toolchain` does not have the necessary
providers for using the make variables and the re-exporting of the make
variables from the `toolchain` in the `current_toolchain` rule did not
seem to work.

This PR removes the provider construction in the `toolchain` and does
that only in the `current_toolchain`. This better mirrors how the Python
toolchains are setup (grepping `PYTHON3` is sufficient to get examples).
This also splits out work done in bazel-contrib#2059 to decrease its scope, so that
this can be discussed separately.

Work towards bazel-contrib#1975

…2059)

Before this change the `all_requirements` and related constants will
have
packages that need to be installed only on specific platforms and will
mean
that users relying on those constants (e.g. `gazelle`) will need to do
extra
work to exclude platform-specific packages. The package managers that
that
support outputting such files now include `uv` and `pdm`. This might be
also
useful in cases where we attempt to handle non-requirements lock files.

Note, that the best way to handle this would be to move all of the
requirements
parsing code to Python, but that may cause regressions as it is a much
bigger
change. This is only changing the code so that we are doing extra
processing
for the requirement lines that have env markers. The lines that have no
markers
will not see any change in the code execution paths and the python
interpreter
will not be downloaded.

We also use the `*_ctx.watch` API where available to correctly
re-evaluate the
markers if the `packaging` Python sources for this change.

Extra changes that are included in this PR:
- Extend the `repo_utils` to have a method for `arch` getting from the
`ctx`.
- Change the `local_runtime_repo` to perform the validation not relying
on the
  implementation detail of the `get_platforms_os_name`.
- Add `$(UV)` make variable for the `uv:current_toolchain` so that we
can
  generate the requirements for `sphinx` using `uv`.
- Swap the requirement generation using `genrule` and `uv` for `sphinx`
and co
so that we can test the `requirement` marker code. Note, the
`requirement`
  markers are not working well with the `requirement_cycles`.

Fixes bazel-contrib#1105.
Fixes bazel-contrib#1868.
Work towards bazel-contrib#260, bazel-contrib#1975.
Related bazel-contrib#1663.

---------

Co-authored-by: Richard Levasseur <rlevasseur@google.com>

…thon (bazel-contrib#2135)

Before this PR the lockfile would become platform dependent when the
`requirements` file would have env markers. This was not caught because
we do not have MODULE.bazel.lock checked into the `rules_python`
repository because the CI is running against many versions and the lock
file is different, therefore we would not be able to run with
`bazel build --lockfile_mode=error`.

With this change we use the label to `BUILD.bazel` which is living next
to the `python` symlink and since the `BUILD.bazel` is the same on all
platforms, the lockfile will remain the same.

Summary
* refactor(uv): create a reusable macro for using uv for locking reqs.
* test(bzlmod): enable testing the MODULE.bazel.lock breakage across
platforms.
* test(bzlmod): use a universal requirements file for 3.9.
This breaks the CI, because the python interpreter file hash is added to
the lock file.
* fix(bzlmod): keep the lockfile platform independent when resolving
python


Fixes bazel-contrib#1105 and bazel-contrib#1868 for real this time.
Implements an additional helper for bazel-contrib#1975.

This PR starts establishing a structure that will eventually become a
part of our API. This is a prerequisite for bazel-contrib#2578 which removes the
versions.bzl file in favour of a more dynamic configuration of the
extension. We also remove the `defs.bzl` to establish a one symbol per
file convention.

Things that I wish we could change is `//python/uv:extensions.bzl` and
the fact that we have `extensions` in the load path. I think it cannot
be removed, because that may break the BCR test. On the other hand,
maybe we could remove it and do an alpha release to verify this
assumption.

Work towards bazel-contrib#1975

…s_python (bazel-contrib#2578)

Finalize the `uv` extension interface employing a builder pattern so
that the users can specify the exact version that needs to be
registered.
This also moves the registration of the actual toolchain to
`rules_python`
itself and ensures that an incompatible noop toolchain is registered if
nothing is configured. This ensures that the
`register_toolchains("@uv//:all")`
never fails.

If the `url/sha256` values are not specified, this is falling back to
using the `dist-manifest.json` on the GH releases page so that
we can get the expected `sha256` value of each available file and
download all of the usable archives. This means that `rules_python` no
longer needs to be updated for `uv` version bumps.

The remaining bits for closing the ticket:
- [ ] Finalize the `lock` interface.
- [ ] Add the locking target to the `pip.parse` hub repo if
`pyproject.toml`
    is passed in.
- [ ] Add a rule/target for `venv` creation.

Work towards bazel-contrib#1975.

This change re-implements the `uv pip compile` as a set of rules instead
of
using a `genrule`. This makes the setup more RBE friendly and it also
fixes
some of existing issues in the exec tools toolchain.

The `lock` macro in the `//python/uv:lock.bzl` now creates three public
targets: `<name>`, `<name>.update` and `<name>.run`. The first will
provide you
with the locked `requirements.txt` file that is used in the
`<name>.update`
executable target when updating the in-source copy of the file. The
`<name>.run` provides an executable target that hardcodes all of the
`uv` args
from the `<name>` rule in a shell script and allows user to debug the
execution
and add extra arguments at the command line.

The `test` target is no longer included, but users can define it
themselves
with the help of `native_test`.

Things that I could not test and would benefit from the community help:
* Windows support - the repository has a rudimentary script, but I am
almost
  sure that it is likely not working, so PRs there are welcome.
* The integration tests are not running on RBE because of the current
RBE
  cluster setup. If you see issues in your RBE setup, PRs are welcome.
* `keyring` integration to pull packages from private index servers is
untested
  as of now, but I see no reason why it should not work.

Work towards bazel-contrib#1325
Work towards bazel-contrib#1975
Related bazel-contrib#2663

…b#2769)

This change fixes a bug in the `lock` rule where, when the package is at
the root level, the path to `requirements.txt` is constructed
incorrectly with a leading double slash (`//requirements.txt`), causing
it to be interpreted as an absolute path.

This change detects if the package is empty before constructing the
output path.

Work towards bazel-contrib#1975

---------

Co-authored-by: Ignas Anikevicius <240938+aignas@users.noreply.github.com>

This allows one to download the uv binaries from private mirrors.

The plumbing of the auth attrs allows us to correctly use the `~/.netrc`
or the credential helper for downloading from mirrors that require
authentication.

Testing notes:
* When I tested this, it seems that the dist manifest json may not work
  with private mirrors, but I think it is fine for users in such cases
  to define the `uv` srcs using the `urls` attribute.

Work towards bazel-contrib#1975.