//python/uv:lock.bzl

Theuv locking rule.

Differences with the legacycompile_pip_requirements rule:

  • This is implemented as a rule that performs locking in a build action.

  • Additionally one can use the runnable target.

  • Usesuv.

  • This does not error out if the output file does not exist yet.

  • Supports transitions out of the box.

Note, this does not provide a test target likecompile_pip_requirements does.Theuvpipcompile command is not hermetic and thus a test based on it would most likely be flaky:

  • It may require auth injected into it, so most likely it requires a local tag added so that the bazel action runs without sandboxing.

  • It requires network access.

Given those points, a test target should be an explicit and properly documented target and not a hidden implicit target.If, you would like to add a test target that always does the locking automatically to ensure that therequirements.txt file is up-to-date, add something similar to:

load("@bazel_skylib//rules:native_binary.bzl","native_test")load("@rules_python//python/uv:lock.bzl","lock")lock(name="requirements",srcs=["pyproject.toml"],)native_test(name="requirements_test",src="requirements.update",)

EXPERIMENTAL: This is experimental and may be changed without notice.

lock(name,srcs,out,args=[],build_constraints=[],constraints=[],env=None,generate_hashes=True,python_version=None,strip_extras=False,**kwargs)

Pin the requirements based on the src files.

This macro creates the following targets:

  • name: the target that creates the requirements.txt file in a buildaction. This target will haveno-cache andrequires-network addedto its tags.

  • name.run: a runnable target that can be used to pass extra parametersto the same command that would be run in thename action. This willupdate the source copy of the requirements file. You can customize theargs via the command line, but it requires being able to runuv (andpossiblypython) directly on your host.

  • name.update: a target that can be run to update the source-tree versionof the requirements lock file. The output can be fed to thepip.parse bzlmod extension tag class. Note, you can usenative_test to wrap this target to make a test. You can’t customize theargs via command line, but you can use RBE to generate requirements(offload execution and run for different platforms). Note, that for RBEto be usable, one needs to ensure that the nodes running the action haveinternet connectivity or the indexes are provided in a different way fora fully offline operation.

Note

All of the targets havemanual tags as locking results cannot be cached.

Args:

  • name –(str)

    The prefix of all targets created by this macro.

  • srcs –(list[Label])

    The sources that will be used. Add all of thefiles that would be passed as srcs to theuvpipcompile command.

  • out –(str)

    The output file relative to the package.

  • args –(list[str])(default[])

    The list of args to pass to uv. Note, these arewritten into the runnablename.run target.

  • build_constraints –(list[Label])(default[])

    The list of build constraints to use.

  • constraints –(list[Label])(default[])

    The list of constraints files to use.

  • env –(dict[str,str])(defaultNone)

    the environment variables to set. Note, thisis passed as is and the environment variables are not expanded.

  • generate_hashes –(bool)(defaultTrue)

    Generate hashes for all of therequirements. This is a must if you want to usepip.parse.experimental_index_url. Defaults toTrue.

  • python_version –(str|None)(defaultNone)

    the python_version to transition towhen locking the requirements. Defaults to the default python versionconfigured by thepython module extension.

  • strip_extras –(bool)(defaultFalse)

    whether to strip extras from the output.Currentlyrules_python requires--no-strip-extras to properlyfunction, but sometimes one may want to not have the extras if youare compiling the requirements file for using it as a constraintsfile. Defaults toFalse.

  • kwargs – common kwargs passed to rules.