For every implementation we support an extra passthru attribute with the
name of the implementation is created which points to a version of the
derivation built with that implementation. E. g. if we support CCL, ECL
and SBCL, third_party.lisp.alexandria would have:
* third_party.lisp.alexandria.sbcl
* third_party.lisp.alexandria.ecl
* third_party.lisp.alexandria.ccl
To make this possible, the REPL derivation which was called `sbcl`
originally has been renamed to `repl`.
Since some things won't build with all implementations, we introduce a
brokenOn argument which influences the meta.targets list that is
created, but won't prevent the passthru attrs from being created to
ease debugging failures.
Change-Id: Icd6af345143593fac30ded10deabf31172e5d48a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3359
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Both the deps and srcs arguments may now have special “filter sets” in
the lists they receive as arguments. When building, buildLisp checks if
such sets either have a attribute named like the current implementation
or a "default" attribute. If yes, the set is replaced by the respective
attribute's value. If no, the set is removed from the list without
replacement.
This can be used to add elements for (a) specific implementation(s):
{ sbcl = buildLisp.bundled "sb-posix"; }
{ sbcl = ./sbcl/optional-sbcl.lisp; }
or to switch between files for different implementations:
# If a implementation case is missing and no default set present,
# no file will be added. Compilation will likely fail as a result.
{
ecl = ./tf-ecl.lisp;
ccl = ./tf-ccl.lisp;
sbcl = ./tf-sbcl.lisp;
}
or to account for special behavior for a certain implementation:
{
ccl = ./ccl-quirk-impl.lisp
default = ./ansi-impl.lisp;
}
Change-Id: I082c3701d1f5063b92100bf336a83425471c269d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3321
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
By implementing a bundled function for an implementation, we can use a
custom one for a specific implementation. This is useful for
implementations like ECL where a require will be compiled as an
instruction rather than importing all new symbols into a dump, so using
the underlying static or shared object directly would be beneficial.
overrideLisp for bundled libraries now only allows overriding the name
and implementation arguments.
Change-Id: I9036b29157e8daa4d86ff87d603b044373711dbf
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3301
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Concept is roughly:
* receive extra argument `implementation` that refers to the name of an
implementation or rather an attribute in an internal attribute set
telling buildLisp how to do certain build steps.
* We assume an implementation can execute lisp files as scripts and that
we can implement the following main tasks in lisp:
- Building a library (`genCompileLisp`)
- Building an executable (`genDumpLisp`)
- Loading a library dynamically (`genLoadLisp`)
Based on that we can implement:
- Running a test suite (`genTestLisp`)
- A REPL preloaded with a libraries and their dependencies (`lispWith`)
Additional attributes for implementing these parts genericly are
added as needed (`faslExt` and `runScript`).
* `genCompileLisp` no longer prints a shell script which concatenates
the individual FASLs. Instead it does the step previously done by the
shell script itself. In essence `genCompileLisp` now writes a lisp
script which compiles and installs the library to build.
This will allow us extra freedom for different implementations, e. g.
for ECL we'll want to build a object file archive additionally to fasl
files in order to be able to link proper executables.
* `genLoadLisp` and `genTestLisp` are almost generic (the former just
sometimes would need to use different file extensions), but we
integrate them into the implementation “API” to facilitate minor
tweaks we need to do like the `fasc` extension for ECL's native FASL
files.
Change-Id: I1b8ccc0063159638ec7af534e9a6b5384e750193
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3292
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
To be fair this hardly matters since SBCL is quite fast, but compiling
ironclad with ECL is quite the experience…
Change-Id: Ib89cc50e5d557acec51fdb085bcbdfc99736221e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3342
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
`makeOverriddable` doesn't work for bundled sbclWith as is because it
uses the `//` operator internally which doesn't work with the types
`bundled` and `sbclWith` accept as arguments (string and list
respectively).
What's more, `bundled` already uses `makeOverridable` and allows to
override the internal call to `library` via `overrideLisp`. For
`sbclWith` no such mechanism exists, but this seems to be no concern for
now: Using `overrideLisp` for this hasn't worked so far (and failed with
a _hideous_ evaluation error), so there doesn't seem to be any real
demand for this feature. Maybe a feature for another CL.
Change-Id: I0b2f34c00a2143cd66dd43a6b1b2880af997ee50
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3296
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Using passthru and appending the attributes via `//` have the same
effect with a subtle difference: In the latter case re-evaluating
the derivation when using the underlying `mkDerivation`'s
`overrideAttrs` will delete all appended attributes. Using
passthru at least preserves the attributes although the self
reference to the derivation in `passthru.sbcl` will become
outdated (unless updated manually).
Change-Id: I8b85009f386b9375b86a23fd50c4ec8c6a9dea7f
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3257
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: grfn <grfn@gws.fyi>
We can be closed world, so let’s restrict the arguments to the subset
we need for now.
The existing override was wrong, in that `// args` would use the
arguments we already added, again. So instead of deliberating about
how to make this work right in all cases, we don’t need it, we trim
it.
Change-Id: I6443a0808b8bfd5e4db939b669c6afc741954db8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3057
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
I think it’s solid enough to use in a wider context.
Change-Id: If53e8bbb6b90fa88d73fb42730db470e822ea182
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3055
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: lukegb <lukegb@tvl.fyi>
Moving to toplevel so I can use them with `runExecline`. They should
be pretty atomic, and are proven to work (tests are still in my user
dir, since they test the producers indirectly via the python parser
and I don’t want to pull it out right now).
Change-Id: Id0baa3adcb2ec646458a104c7868c2889b8c64f5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3054
Reviewed-by: Profpatsch <mail@profpatsch.de>
Tested-by: BuildkiteCI
When a foreign dep is missing a dependency, it is good to have a
context.
e.g. the `github.com/charmbracelet/bubblegum` package has a lot of
dependencies that are only used in its `examples/` dir; this is not
obvious, unless we also print where the imports come from.
New error message:
```
error: missing foreign dependency 'github.com/containerd/console' in 'github.com/charmbracelet/bubbletea, imported at /nix/store/0cry4sg6bzxqwk5zl2nxhas6k5663svg-source/tea.go:22:2'
```
Change-Id: If34a3c62b9d77d4aea108b5e011e16fbd03e8554
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2852
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
This is a wrapper around baseNameOf which also can deal with
derivations. Added to //nix/utils since I've found myself introducing an
ad-hoc implementation of this for both //web/bubblegum and //nix/buildC.
Change-Id: I2fcd97a150d6eda21ab323fa0d881ff7442a892e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3049
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Instead of having two ways of accessing the path to the depot (one of
which was stuttering, depot.depotPath) we settle on only one:
depot.path.
This was mostly used for NixOS module imports.
Co-Authored-By: Florian Klink <flokli@flokli.de>
Change-Id: I2c0db23383fc34f6ca76baaad4cc4af2d9dfae15
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2962
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Reviewed-by: sterni <sternenseemann@systemli.org>
Plumbs an additional internal argument through readTree that indicates
whether the top-level of a tree is being read, and avoids recursing
into itself in that case. This changes the externally visible
behaviour of readTree (it is now expected to be called a level higher
than previously).
This allows us to reduce the amount of boilerplate needed to bootstrap
the TVL repository (by not having to specify the individual folders
that need to be read).
For reasons related to an infinite recursion we could not (be bothered
to) debug, the top-level `config` key (which held the attribute set
passed on by readTree) has been removed. This is not needed, as it is
already passed on by readTree ...
Co-Authored-By: Florian Klink <flokli@flokli.de>
Change-Id: Id6e39b57b2f5b3473c4b695a72dd1d01fcfb7a66
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2961
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: grfn <grfn@gws.fyi>
This should ease migrating to a distinction between depot.third_party
and pkgs (as in nixpkgs) in the future.
Ref cl/2910, b/108.
Change-Id: I53a854071fddd7c0d0526cc4c5b16998202082c6
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2913
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Very simple builder which builds (optionally) gzipped man pages from a
list of attrsets and links them into a common man directory with the
correct layout, so it should be installable immediately.
Additionally runs mandoc -T lint, but by default only for informational
purposes as it is very strict and some things are almost never true (for
example all Xrs being present in the respective directory).
buildManPages.single exposes the internal builder for a single,
optionally gzipped man page from a nix attrset.
Change-Id: I43fce011716f4a7cc80521f222800ca99ba54060
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2654
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Same as 221698c603dcb318c609b4d21cb2a9fada44a14c
We had a bunch of instances of
https://github.com/NixOS/nix/issues/2176,
where nix would exit with a “killed by signal 9” error.
According to Eelco in that issue, this is perfectly normal behaviour
of course, and appears if the last command in a loop closes `stdout`
or `stdin`, then the builder will SIGKILL it immediately. This is of
course also a perfectly fine error message for that case.
It turns out that mainly GNU coreutils exhibit this behaviour …
Let’s see if using a more sane tool suite fixes that.
Change-Id: Iaf9e542952ca36c02208a3f067f575ba978272b4
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2663
Reviewed-by: Profpatsch <mail@profpatsch.de>
Tested-by: BuildkiteCI
I'm looking at removing some of these because they can cause
unnecessary build steps during CI pipeline generation.
Change-Id: I84742968918090c050d2eedab8a1b42692632a42
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2655
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
Setting meta.targets to include all derivations in the different package
sets in Profpatsch's user folder makes them checked by CI until they do
the readTree refactor as promised.
To reduce code duplication we handle this in a simple function which is
exposed from nix.utils which may be a good place for depot specific bits
and bops we accumulate over time.
To get around the issue of too nested sets we perform the following
renames:
* users.Profpatsch.tests gets moved into its own directory
* users.Profpatsch.arglib.netencode now lives in its own file instead of
the default.nix
* users.Profpatsch.netstring.tests gets moved into its own directory
Change-Id: Icd039c29d7760a711c1c53554504d6b0cd19e120
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2603
Tested-by: BuildkiteCI
Reviewed-by: Profpatsch <mail@profpatsch.de>
Go 1.16 makes "go list all" not work. "go list std" is what we should be
using instead anyway.
Change-Id: I3f867fde477030d2358085b3d64b5856fb9c421b
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2551
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
When a file is added to the depot tree that is picked up by read-tree,
but it’s not a function like ({...}: {}), `readTree` will fail on the
function application, leading to a bad error message.
We can do slightly better, by checking the type and throwing a nicer
trace message.
`assertMsg` is copied from `nixpkgs/lib/assert.nix`, since at this
point we don’t have a reference to the lib.
There is another evaluation failure that can happen, which is when the
function we try to call does not have dots; however, nix does not
provide any inflection capabilies for checking whether a function
attrset is open (`builtins.functionArgs` only tells us the attrs it
mentions explicitly). Maybe the locality of the error could be
improved somehow.
Change-Id: Ibe38ce78bb56902075f7c31f2eeeb93485b34be3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2469
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Previously, for types defined using typedef (like all primitive types)
type.checkType would return a boolean. This is largely fine since in
most places `type.checkToBool (type.checkType x)` or similar is used.
However, some functions actually take type.checkType up on the promise
that it returns a set of the form:
{
ok = <bool>;
err = <option string>;
}
This is the case for restrict which has checkToBool = v: v.ok; and will
generate a proper set except if `t.checkToBool (t.checkType v) == false`
in which case it will return t.checkType v. If t was a primitive type or
defined using typedef, previously `t.checkType v` would be a boolean
which meant as soon as (restrict …).checkToBool was called on a restrict
checkType result in cases where the wrapped type didn't match, an
unrelated error would be thrown:
nix-repl> with nix.yants; restrict "foo" (_: true) int "lol"
error: value is a boolean while a set was expected, at /home/lukas/src/depot/nix/yants/default.nix:38:39
This is fixed by making typedef return a proper set from checkType and
adjusting its checkToBool accordingly.
Unfortunately I don't think we can easily add test cases for this except
by using recursive nix or VM tests as there is no way to introspect
error messages.
Change-Id: I96a7be065630f04ca33358f21809284911ec14fe
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2536
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: Profpatsch <mail@profpatsch.de>
Nix unfortunately has terrible escaping syntax: If something is an
escape sequence it does not know, like \0, it just swallows the
backslash and returns the second character (byte) as is (yes,
"\0" == "0" is true). This created the following bug in nixFileName
which should have resulted in at least a parse error: "(.*)\.nix" is
the same as "(.*).nix" which meant that nixFileName matched anything
that is at least 4 characters long and ends in "nix". This lead to
readTree creating double attributes when directories are involved or
attributes for non-nix files.
Change-Id: Ibf3be2bd189d48881c82ee795c50151bfb365627
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2535
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
This adds the star of NixCon 2017 from vuizvui, slightly reformatted and
now using yants. While it has some flaws, I realized that it is ideal to
run the tests of rustSimple{Lib,Bin} where the normal and the -tests
variant would have to be rebuilt if either the tests or the library /
executable itself changes.
Change-Id: Ie8f84f98c51c9fafc046eff916c8f0df7e8f224b
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2528
Tested-by: BuildkiteCI
Reviewed-by: Profpatsch <mail@profpatsch.de>
By using an extremely trivial derivation we can ensure that it will not
throw if evaluated using deepSeq. When using stdenv.mkDerivation or
similar at some point something will most likely throw or generate some
kind of error which is alright in the context of nixpkgs, but makes
testing yants harder than you'd think it should be.
Change-Id: I61ff7dc01a00a4815ef39066e4e223123356ddd5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2507
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Port existing tests to runTestsuite and add some obvious additional
tests that wouldn't be possible before (using assertThrows and
assertEq).
Change-Id: Ibe950a7a0cda3e23ebb226bdff35f52cdfec5ddf
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2479
Tested-by: BuildkiteCI
Reviewed-by: Profpatsch <mail@profpatsch.de>
Reviewed-by: tazjin <mail@tazj.in>
assertDoesNotThrow is like assertThrows, but fails if the expression
throws. In that case the new unexpected-throw branch of AssertErrorContext
is returned.
Change-Id: I7195eb5df8965456e9ab9b69e35ec96b33f00a35
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2476
Tested-by: BuildkiteCI
Reviewed-by: Profpatsch <mail@profpatsch.de>
Refactor assertEq and assertThrows to be implemented in terms of a more
generic assertBool to reduce code duplication and ease adding new assert
types.
To preserve meaningful error messages AssertResult is changed slightly:
nope-eq and nope-throw have been replaced by a single nope branch which
contains an AssertErrorContext which contains error information. To
implement an assert assertBoolContext (which is not exposed) can be
used: It takes an AssertErrorContext which is returned in case of an
error and a boolean determining whether the assert was successful.
The currently possible AssertErrorContext are:
* should-throw: error result of assertThrows, formerly nope-throw
* not-equal: error result of assertEq, formerly nope-eq
Change-Id: Ifd6b3aa4187c90c3add2df63fa7c906c8f03fd2d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2473
Tested-by: BuildkiteCI
Reviewed-by: Profpatsch <mail@profpatsch.de>
Introduces the concept of a “tag”, a single-keyed attrset which
annotates a nix value with a name.
This can be used to implement tagged unions (by implying the list of
possible tags is well-known), which has some overlap with how
`nix.yants` does it.
However, the more fascinating use-case is in concert with a
so-called discriminator, `match` and hylomorphisms.
The discriminator can take a nix value, and add tags to it based on
some predicate.
With `match`, we can then use that information to convert the
discriminated values again.
With `hylo`, we can combine both the “constructive” discriminator step
with the “destructive” match step to recursively walk over a nix data
structure (based on a description of how to recurse, e.g. through attrset
values or list values), and then apply a transformation in one go.
Change-Id: Ia335ca8b0881447fbbcb6bcd80f49feb835f1715
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2434
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
This should closely match the documented behaviour. It might still be
missing some edge cases of course.
Change-Id: I5c75fa045d5f3be8cf5eab787a02644500c14522
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2466
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
First step to slowly giving readTree some coverage, so we can do
refactoring without breaking functionality.
Change-Id: If25a8c0fa9c4ac7472c0473372f10a9326cccaf7
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2465
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
We are going to export some tests under `nix.readTree.tests`, so in
order to do that and still have `nix.readTree` be a function, let’s
move it to `__functor`.
This requires wiring the `args` and `initPath` arguments through
explicitly.
Change-Id: Ife7956b85d35e59c22174b42dcb7cca83ed868ea
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2464
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
Uses `builtins.tryEval` to check that the expression throws when
`deepSeq`-ed.
Change-Id: I0d57cc37f473bb733f57a1b1c0d889084152fd2f
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2463
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Previously we would throw or return `{}`, which doesn’t integrate
nicely into our CI; thus, let’s wrap it into a derivation which either
fails the build or doesn’t.
Change-Id: I65880d86b8393094661e57a0b32aafe748bf1dd5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2462
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
Nobody has actually done any experimentation with typed Go, so we're
getting rid of it for now - it's causing annoying IFD during build
graph generation.
Change-Id: Ibac3dea98ebed1b3ee08acda184d24c500cf695d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2458
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
Reviewed-by: lukegb <lukegb@tvl.fyi>
Reviewed-by: Profpatsch <mail@profpatsch.de>
`restrict` uses a predicate function to restrict a type, giving the
restricting a descriptive name in the process.
First, the wrapped type definition is checked (e.g. int) and then the
value is checked with the predicate, so the predicate can already
depend on the value being of the wrapped type.
Change-Id: Ic3edde45a8f34c31bc164414580d0a1aa5a821d5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2312
Tested-by: BuildkiteCI
Reviewed-by: Profpatsch <mail@profpatsch.de>
Reviewed-by: tazjin <mail@tazj.in>
Similar to runCommandLocal, this turns off substitutions and prefers
building locally.
Change-Id: I823b34c7fc54990b54a82324172c299aeffdbf41
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2309
Tested-by: BuildkiteCI
Reviewed-by: Profpatsch <mail@profpatsch.de>
Reviewed-by: lukegb <lukegb@tvl.fyi>
I can review all nix-related changes.
Change-Id: I13e5bb7b523d4b9c79dbe2083d9e23c217466651
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2308
Tested-by: BuildkiteCI
Reviewed-by: lukegb <lukegb@tvl.fyi>
Machines on which LANG is misconfigured have trouble with SBCL loading
files that contain characters in certain encodings. This overrides
whichever local LANG (if any) is set.
Change-Id: Ic4341a01c4393e7f697de6cecc58dea4f2d85987
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2076
Tested-by: BuildkiteCI
Reviewed-by: glittershark <grfn@gws.fyi>
This is required to automatically walk the tree (see subsequent
commits).
Note: Lisp packages are removed from the CI builds in this commit
because the attrValues of third_party.lisp will contain an element
that is simply `true`, which causes a type error.
These packages are re-added when CI refactoring is complete.
Change-Id: I21e2b719e6c7161c23d2867a216f4daa1c6c8394
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1848
Tested-by: BuildkiteCI
Reviewed-by: glittershark <grfn@gws.fyi>
Expose an `sbcl` attribute on packages and programs, to allow for easier
development either with SLY or on a REPL.
Change-Id: Ide4d087a5223561e1fe192ef32dc593c54b5a20e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1834
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
depot-scanner is a tool that runs Nix and parses the --trace-file-access output to deduce what files are necessary to evaluate a derivation.
Take DEPOT_ROOT from the environment. If depotRoot doesn't exist, print an error early.
Fix the build of the protobuf library. Switch to the GRPC build rule, as a service is in this proto file.
Create the PathType enum and parse it from cmdline flags.
Change-Id: I537b5c6bceecf76ca510f7ac04ab9dad7785feb1
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1769
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: lukegb <lukegb@tvl.fyi>
This accepts a function for args, and passes it an attrset containing
the locatedAt parameter.
Change-Id: I3c0f8ca00605e02a787fda88f32b06f5ef9998f2
Reviewed-on: https://cl.tvl.fyi/c/depot/+/1639
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
