Rahul Butani rrbutani

nix flake show git+ssh://[email protected]/286ba7198b92373d4c4d84ea81564980.git

September 5th, 2023

having a bit of a crisis

using platforms to model build environments is broken because of how strategies interact with platforms

bzlmod is conceptually pretty excellent but still has tons of warts and weird limitations that require lots of creative workarounds

We couldn’t find that file to show.

First you need to run echo "test" > /tmp/foo.

Running bazel build @repo//... will print "running repo rule".

Touching test_file and then bazel build @repo//... will not do anything; the repo rule is not rerun and the artifacts in @repo are not rebuilt.

Modifying test_file will cause the workspace rule to be rerun.

if you make a change that yields a different BUILD.bazel file then artifacts will be rebuilt (i.e. changing the first line of test_file)
if you make a change that still yields the same BUILD.bazel file no actions will be run (i.e adding extra lines, whitespace to test_file)

	"""Workarounds for https://github.com/bazelbuild/bazel/issues/19055."""

	# TODO(build, bazel, blzmod): if new APIs are introduced resolving this issue:
	# https://github.com/bazelbuild/bazel/issues/19055, use them in lieu of this
	# function.
	def get_sibling_repo_in_module_extension(rctx, repo_name):
	"""Gets the _canonical_ name for a sibling repo in the module extension.

	## Background

	"""Starlark version of `new_local_repository` for module extensions.

	Currently `native.new_local_repository` cannot be called from Bazel module
	extensions: https://github.com/bazelbuild/bazel/issues/15412

	The plan is to eventually "starlark-ify" this rule:
	- https://docs.google.com/document/d/17RZKMuMjAIgNfFdrsLhqNsMTQDSS-BBA-S-fCSBPV7M/edit
	- https://github.com/bazelbuild/bazel/issues/18285

	In the interim we've got our own Starlark-native `new_local_repository`

	"""Helper functions for repository rules that ensure labels are well-formed.

	Labels constructed and used within repository rules do not have their name (the
	part after `:`) checked against the package structure of the repo they point to;
	they are allowed to refer to source artifacts via paths that do not respect the
	package structure or visibility.

	For example, for a source file that lives at `@foo//bar/baz:some/file/path`, all
	of the following — when passed to repository context functions like `rctx.path`
	or `rctx.read` — will refer to the file, without error:

	{ lib }: {
	# Given an attrset of derivations of interest, returns an attrset where each
	# corresponding key is the full list of deps for the derivation.
	#
	# Note: this is far from perfect; this function only walks the usual
	# `mkDerivation` dependency list attributes so it'll miss dependencies in
	# strings.
	collectDeps = pkgSet: let
	# dbg = x: builtins.trace (builtins.typeOf x) (builtins.trace x x);
	d = path: builtins.unsafeDiscardStringContext path;

	Meant to be used together with this Bazel fork:
	- https://github.com/rrbutani/bazel/compare/70fc57d29ce21204f28f8462627badbd5b750787...b8553d4fcf157acddbac855a3945c74d0f962c27