Status: implemented
Author: dmarting@google.com
Reviewers: lberki@google.com, laurentlb@google.com, kchodorow@google.com
Skylark is the extension language for Bazel and lets Bazel users describe the build for new languages easily. External users do not create native rules and we want to avoid them doing so.
Remote repositories are a convenient way to specify your third party dependencies and to fetch them along with the build if you don’t want to check them in your repository.
This document discuss “Skylark Remote Repositories”, that is creating new remote repository rules using Skylark.
The load statement will now be available from the WORKSPACE, working the same way it does for build file but with WORKSPACE specific functions instead.
In the same way that we have macros and rules for the BUILD file, we are going to have macros and rule for the WORKSPACE file. The former will be a convenient way to combine remote repositories and the latter enable creation of new repositories kind.
Skylark macros would be activated in the WORKSPACE file and would behave as expected. Macros would enable to combine remote repositories creation and bind into a single rules E.g. setup_java()
would set-up all bindings and the local repository needed to build java target:
def setup_java(): native.new_local_repository(name = “jdk-local”, path = “/usr/share/java/jdk8”, build_file = “jdk.BUILD”) for target in ["jni_header", "jni_md_header", "langtools", "bootclasspath", "extdir", "toolchain", "jdk", "java", "javac", "jar"]: native.bind(name=target, actual="@%s//:%s" % (name, target)) native.bind(name="jni_md_header-linux", actual="@%s//:jni_md_header" % name) native.bind(name="jni_md_header-darwin", actual="@%s//:jni_md_header" % name)
A remote repository rule would be set-up the same way we set-up a build rule but with the repository_rule
statement:
jdk_repository = repository_rule( implementation = my_impl, attrs = { “java_home”: attr.string(mandatory=False), “java_version”: attr.string(default=“1.8”), }
This statement takes only 2 arguments: an implementation function and a list of attributes. The syntax is similar to the rule statement but attributes can only takes primitive type (String, Label, Integer, Boolean, …) and not artifacts.
The implementation function takes exactly one argument: the repository context. This context will provides many convenience methods for doing non hermetic operations, e.g., :
ctxt.os
),ctxt.execute
) to discover the environment,ctxt.download
),ctxt.path(...).uncompress(outputPath)
),ctx.fetch_path(...)
),ctxt.build_file(...)
)The precise list of methods the repository context will support will be augmented on-demand depending on what makes sense for our users.
A preliminary quick and dirty prototype can be found here and here.
Here what the prototype does:
The obvious choice for the roadmap is to remake all those works, correctly commented and tested, and then add methods to the SkylarkRepositoryContext for full support. More precisely the correct order of the work should be: