nixos: Add meta.tests #413892

roberth · 2025-06-04T12:55:44Z

This provides the needed infrastructure to make tooling like ofborg build the relevant tests, given a set of changed files.

Having mandatory CI for modules is not just crucial for DX, but also prerequisite to test-driven expansion of NixOS use cases, such as alternate base module sets. (minimal module list and similar ideas)

The option is documented.
We can provide additional instructional docs elsewhere when this is wired into ofborg.

Why not infer the mapping automatically?

Basically the same reasons we have passthru.tests.nixos.

Too costly. We'd have to evaluate all tests to figure out which ones changed.
For some modules it is not feasible to run all affected tests, because that set is too large. We need a representative smaller set.
This could perhaps be scripted as a one-off or infrequent process that updates the mapping, but then it is time of all evals * *number of files under nixos/... And then there's still some risk that it's not a good mapping for some reason. Doesn't solve (2)

Things done

Add a 👍 reaction to pull requests you find important.

MattSturgeon

Nice idea, this looks useful.

A few minor comments, most of which I could address in a followup if preferred. Some of my comments are more questions than feedback.

maintainers/nixos-tests-for-files.nix

MattSturgeon · 2025-06-06T23:34:23Z

nixos/modules/misc/meta.nix

@@ -39,6 +39,64 @@ let
    #   { file = "module location"; value = <path/to/doc.xml>; }
    merge = loc: defs: defs;
  };
+
+  /**
+    Custom type for `meta.tests` option.


This is kinda redundant given the name & context, however many of the other custom types in this file describe how the value is merged; e.g.

# Returns tuples of # { file = "module location"; value = <path/to/doc.xml>; }

and

# Returns list of # { "module-file" = [ # "maintainer1 <[email protected]>" # "maintainer2 <[email protected]>" ]; # }

Something like that may be more useful here 🙂

A complete and accurate description of the input and output needs to be in the user facing documentation anyway, so I prefer to refer to that, rather than copy it to here.

MattSturgeon · 2025-06-06T23:35:00Z

nixos/modules/misc/meta.nix

+  */
+  testsType = lib.mkOptionType {
+    name = "tests";
+    check = value: lib.isFunction value;


Was this intentional?

Suggested change

check = value: lib.isFunction value;

check = lib.isFunction;

MattSturgeon · 2025-06-06T23:37:39Z

nixos/modules/misc/meta.nix

+            An attrset structure of <testName>.<fileName> = derivation;
+          */
+          transposed = lib.zipAttrsWith (_k: lib.mergeAttrsList) (
+            lib.mapAttrsToList (fileName: values: lib.mapAttrs (k: v: { "${fileName}" = v; }) values) relevant


Again, was this intentional?

Suggested change

lib.mapAttrsToList (fileName: values: lib.mapAttrs (k: v: { "${fileName}" = v; }) values) relevant

lib.mapAttrsToList (fileName: lib.mapAttrs (k: v: { "${fileName}" = v; })) relevant

Not really important, I'm just curious if you have a preference for either code style.

Both are ok. I only have a preference in code that's performance critical, where eta-reduced performs better, producing fewer calls. Shorter error traces can also be nice.

MattSturgeon · 2025-06-06T23:44:19Z

nixos/modules/misc/meta.nix

+
+        This is like `filter`, but solves the problem that `nix-build` ignores attributes with `.` in their names.
+      */
+      filterForNixBuild = paths: lib.concatMap lib.attrValues (lib.attrValues (filter paths));


Would this be more readable as a pipe?

Suggested change

filterForNixBuild = paths: lib.concatMap lib.attrValues (lib.attrValues (filter paths));

filterForNixBuild = paths: lib.pipe paths [

filter

builtins.attrValues

(builtins.concatMap builtins.attrValues)

];

Although, more verbose so maybe not worth it.

Alternatively, how about using collect isDerivation? Maybe this would be less efficient, but it might convey the intention more clearly:

Suggested change

filterForNixBuild = paths: lib.concatMap lib.attrValues (lib.attrValues (filter paths));

filterForNixBuild = paths: lib.collect lib.isDerivation (filter paths);

?

but it might convey the intention more clearly:

It somewhat blurs the intent, because it's two layers and not something arbitrarily deep.
I'll add:

# Two calls to `attrValues` because we have exactly two layers to flatten.

MattSturgeon · 2025-06-06T23:46:29Z

nixos/modules/misc/meta.nix

+
+          This can be used for tooling to figure out which tests are relevant, given a set of changed files.
+        '';
+        default = { ... }: { };


Suggested change

default = { ... }: { };

default = { ... }: { };

defaultText = lib.literalExpression "{ ... }: { }";

or

Suggested change

default = { ... }: { };

default = _: { };

defaultText = lib.literalExpression "{ nixosTests }: { }";

I'm un-documenting the default because it's niche and un-interesting.
The description covers it all.
That also means I won't add an example (not that you were suggesting to), as that would be confusing because the definitions and option value are so different.

MattSturgeon · 2025-06-06T23:50:41Z

nixos/modules/misc/meta.nix

+
+          Definitions are tied to the location of the module, so the definition syntax is distinct from the option value format.
+
+          Example definition:


Suggested change

Example definition:

For example, this definition:

MattSturgeon · 2025-06-06T23:50:52Z

nixos/modules/misc/meta.nix

+          }
+          ```
+
+          Example option value:


Suggested change

Example option value:

Would produce the following option value:

MattSturgeon · 2025-06-06T23:51:46Z

nixos/modules/misc/meta.nix

+          ```nix
+          # module.nix
+          {
+            meta.tests = { nixosTests }:


Nit: nixfmt would format like this:

Suggested change

meta.tests = { nixosTests }:

meta.tests =

{ nixosTests }:

Should the example be consistent?

wolfgangwalther · 2025-06-07T12:29:49Z

maintainers/nixos-tests-for-files.nix

If this is supposed to be used:

manually as a script, it should probably be in maintainers/scripts/....

by CI, then it should be somewhere in ci/.

by ofborg only, then it should be in the ofborg repo (?)

I'd say we want this to be used by CI, too. It would be helpful to expose the list of tests which need to be run in the comparison artifact, so that nixpkgs-review can pick it up and run those tests?

I guess computing a list in nix is too expensive (See roberts explanation in the topic). nixpkgs-review can instead implement a feature to call that function with the list of changed files.

I guess computing a list in nix is too expensive

The file header literally says:

Returns a list of tests for a given list of NixOS module files (and/or other files which will be ignored).

I think you assume I meant to eval all tests for difference. I did not. Same approach, just based on changed files. The goal of this PR is clearly to run stuff in any of the CIs - and I think the location of the file is just wrong for that.

It's just a convenience wrapper really, and I would expect it to be called by CI and maintainers.
maintainers/scripts/ seems like the right place for that. I just forgot to add /scripts.

It's just a convenience wrapper really, and I would expect it to be called by CI and maintainers.
maintainers/scripts/ seems like the right place for that. I just forgot to add /scripts.

I think the script is placed correctly in maintainers/scripts right now, but I don't think this should be the entry-point for OfBorg. Everything in maintainers/scripts should be free to change their interfaces easily, to make the scripts more useful for regular use.

This doesn't need to be figured out in this PR, though. But, we should think about this with #272591 in mind, before taking steps on the OfBorg side.

DavHau

Why not infer the mapping automatically?

Basically the same reasons we have passthru.tests.nixos.

1. Too costly. We'd have to evaluate all tests to figure out which ones changed.

2. For some modules it is not feasible to run all affected tests, because that set is too large. We need a representative smaller set.

3. This could perhaps be scripted as a one-off or infrequent process that updates the mapping, but then it is _time of all evals_ * *number of files under `nixos/`... And then there's still some risk that it's not a good mapping for some reason. Doesn't solve (2)

This reasoning makes sense to me.

I tested the interface and it works fine. I think it's a good idea in general.

wolfgangwalther · 2025-06-18T06:41:08Z

maintainers/nixos-tests-for-files.nix

+  Returns a list of tests for a given list of NixOS module files (and/or other files which will be ignored).
+
+  A more detailed structure than a list is available in the `meta.tests` option value.
+
+  Example:
+    nix-build maintainers/nixos-tests-for-files.nix --arg files '[ nixos/modules/services/databases/postgresql.nix ]'


I tested this - and it doesn't just return a list of tests, but it also builds all of them. Is that intended?

I would have expected to just get back a list of... maybe attributes to build or so? Instead, I just ran 45 VM tests.

nix-build builds whatever you provide it with. If the function returns an attrset, it will build all those attributes.

I guess the question is whether we should be suggesting nix-instantiate instead of or alongside nix-build

And/or rephrase the comment, because that's where my expectation came from.

Changing this to Example usage (to be run from the Nixpkgs root):

I think nix-build is generally what you want when calling this by hand, and I'm sure we can figure out that instantiate is also ok.
If we really want to make this easy, we should add a shell script wrapper with a --dry-run or --eval flag, but let's keep it simple for now.

wolfgangwalther · 2025-06-18T10:36:47Z

Note: I might be missing something in the following, because I don't know the module system well enough. I couldn't find a way to get back a list of the files for the tests belonging to a module.

This would be helpful for things like maintainer pings, for example. If I see a test file is touched and I can connect it easily to modules that depend on this test, then I can ping those maintainers. See also #413097, where the idea is to get module maintainers from changed files for modules.

I think the problem is the indirection through nixosTests. With #386873 in mind, I wonder whether meta.tests could just take a list of paths to the test files? We could then still take this list and runTest on them. I'm not sure how that would work with runTestOn, though.

This would kind of move the definition of "treat this file as a test", which currently happens in all-tests.nix, into the module. Could this eventually replace all-tests.nix and create nixosTests from meta.tests? One step further, this would potentially allow a more "by-name" structure for modules, where I put the postgresql.nix module and all its tests into one directory...

The alternative, to get that mapping back from tests to their file, would be something like meta.position, that we have for packages. Aka runTest could keep track of the imported file name and put it into meta.

Or maybe a combination of both?

TLDR: I'm not sure whether the current interface of { nixosTests }: ... is good.

DavHau · 2025-06-19T05:35:13Z

@roberth

Instead of defining the test inside the module file via meta, would it make more sense to have them declared outside the file via some convention, for example a directory called test or file called tests.nix next to the module?
With your current design we would expect many module files to grow in size and also there could be an evaluation overhead when importing the module.

Apart from that, I'm wondering how exactly it would look like if we used this to test the minimal modules list. Essentially we would want to test if each module individually evaluates successfully against the minimal list of modules. I guess, we probably don't want to modify each individual file to add this generic test to meta.

roberth · 2025-06-21T12:05:18Z

I couldn't find a way to get back a list of the files for the tests belonging to a module.

I don't think the files are what you want, especially if you can have the actual tests, which have meta.maintainers on them.
I guess the reason to use files would be use of CODEOWNERS?

Also relevant:

lib.evalModules: add graph attribute #403839

Could this eventually replace all-tests.nix and create nixosTests from meta.tests? One step further, this would potentially allow a more "by-name" structure for modules, where I put the postgresql.nix module and all its tests into one directory...

Yes, although for nightly CI / build farm duty I think the explicit list may still be more efficient.
Also, if we were to have optional modules that need to be imported by users, we wouldn't have a complete canonical list anymore. For instance, this infrastructure doesn't find tests in profiles.

Other than that, I agree with those thoughts.
Regrouping files by domain is a generally a good thing, with the small caveat that it can be more chaotic in some cases, but I don't think that applies here.

TLDR: I'm not sure whether the current interface of { nixosTests }: ... is good.

It's an attrset argument, so that it can evolve as needed.
My intent is for it to be called through reflection, similar to what callPackage does, but something that suits the transition we wish.

So yes, changes are possible. My goal here is to establish something that works, and I believe it already works quite well this way.

roberth · 2025-06-21T12:13:14Z

evaluation overhead when importing the module.

Non-zero but cheap. We're not actually instantiating the tests, and the test framework's use of lazyDerivation makes sure of that.

Apart from that, I'm wondering how exactly it would look like if we used this to test the minimal modules list.

Currently, you'd might add a _minimal test to all-tests.nix and refer to that.

This also reminds me that the "plain set of test files" approach does not handle which test entrypoint is to be used. It's also not obvious to me how you'd construct a test matrix except adding a bunch of boilerplate files.

Essentially we would want to test if each module individually evaluates successfully against the minimal list of modules. I guess, we probably don't want to modify each individual file to add this generic test to meta.

Making this explicit is a good thing. It shows which modules are tested and maintained in a modular way, and which ones are still part of the module soup.

wolfgangwalther · 2025-06-21T12:15:42Z

I don't think the files are what you want, especially if you can have the actual tests, which have meta.maintainers on them.
I guess the reason to use files would be use of CODEOWNERS?

The files are what I want, because I can match them with the changed files in a PR.

Yes, meta.maintainers for a test is a good thing, too - but it would require all tests to explicitly have maintainers added. Whereas, if I could match the test files with the module files, I would only need to keep the maintainers list in the module up2date. All tests would "automatically belong" to the module.

That should make for much better maintainer pings.

(Not really relevant for codeowners, because codeowners define the file<->owner relationship directly)

It's an attrset argument, so that it can evolve as needed. My intent is for it to be called through reflection, similar to what callPackage does, but something that suits the transition we wish.

So yes, changes are possible. My goal here is to establish something that works, and I believe it already works quite well this way.

Yeah, I don't see the problem with extensibility, but with the fact that the indirect way through nixosTests is available at all. If we were forced to use the other way proposed, aka via direct paths mentioned, everybody would have to do it in a way that works well for the maintainer pings as mentioned above.

wolfgangwalther · 2025-06-21T12:26:07Z

My intent is for it to be called through reflection, similar to what callPackage does, but something that suits the transition we wish.

Because you mention callPackage: I am currently investigating whether callPackage can provide meta.position for packages with much better quality than the current approach via mkDerivation. After all, callPackage already knows about the filename it imports. Or about the location of the function definition. If this works, I'd want to put package maintainer pings on this better meta.position and remove all the approximation in ci/eval/compare/maintainers.nix.

Now, applying the same concept to NixOS tests, that I mentioned earlier:

The alternative, to get that mapping back from tests to their file, would be something like meta.position, that we have for packages. Aka runTest could keep track of the imported file name and put it into meta.

runTest equally knows about the location of the test file. I haven't looked into it, yet, but I imagine it should be able to set meta.position for test files from that file name.

With this approach, the current { nixosTests, ... }: ... interface would work well for my use case, too.

WDYT?

roberth · 2025-06-21T12:27:16Z

Got it. You want it to work for test files too, and for that we need #403839.
So we'd have the following relations:

module file <-> test (this PR)
test <-> test files (#403839)

Alternatively, you could sidestep the module system and make everything directory-based with CODEOWNERS.
That would be neatly organized and have no performance concerns whatsoever.
It just doesn't extend beyond the repo, whereas a module based solution might.

roberth · 2025-06-21T12:30:13Z

runTest equally knows about the location of the test file.

#403839 knows it even better; it knows the whole imports closure, not just the top, and it can see through anonymous modules.

Sgtm, but also no problem to pivot to something else, e.g. directory based, if at some point that seems to be better.

wolfgangwalther · 2025-06-21T12:32:05Z

Got it. You want it to work for test files too, and for that we need #403839. So we'd have the following relations:

module file <-> test (this PR)
test <-> test files (#403839)

OK, cool. If that works, I'm happy.

Alternatively, you could sidestep the module system and make everything directory-based with CODEOWNERS.

Yeah - I have different ideas for codeowners. I ideally want less of them, not more. meta.maintainers is nice, because it's defined in the package/module. And NixOS modules and their tests are nicely isolated in principle, so maintainers should work well there.

wolfgangwalther

I'm not a module-magician, so can't comment much on those parts. The concept is great, my concerns about the interface resolved.

The obvious way to use this is for OfBorg to build NixOS tests. But we should also think about how to integrate this with nixpkgs-review and/or GitHub Actions CI.

Since nixpkgs-review already pulls eval results from GHA, it could also pull a list of nixosTests attributes to build. Alternatively, if not expensive to evaluate, nixpkgs-review could do that itself as well, ofc.

In CI, we could make use of the data, to maybe add labels. I don't think "rebuilds tests" labels with numbers make sense, because we don't really know how many tests/modules would be affected on top of those linked. But maybe something like "has required tests" or something, which gives a quick indication of "Are there any tests associated to the module, that I should watch out for?".

Maintainer pings have already been discussed.

Anything else this could be used for?

wolfgangwalther · 2025-06-21T17:17:05Z

nixos/modules/misc/meta.nix

@@ -39,6 +39,73 @@ let
    #   { file = "module location"; value = <path/to/doc.xml>; }
    merge = loc: defs: defs;
  };
+
+  # TODO: add to lib?
+  resolveDefaultNix = p: if lib.pathType p == "directory" then p + "/default.nix" else p;


To potentially help the decision on the TODO: This is done elsewhere, too:

nixpkgs/lib/customisation.nix

Line 294 in 2147c83

toString fn + optionalString (pathIsDirectory fn) "/default.nix"

I'd removed the TODO while fixing my definition, but actually that made them equivalent, so yes. This should be done, and it should be done in a separate PR.

lib.filesystem.resolveDefaultNix: init #418824

Whichever merges first, I'll adjust the other.

nixos/modules/services/databases/postgresql.nix

wolfgangwalther · 2025-06-21T17:28:24Z

maintainers/nixos-tests-for-files.nix

It's just a convenience wrapper really, and I would expect it to be called by CI and maintainers.
maintainers/scripts/ seems like the right place for that. I just forgot to add /scripts.

I think the script is placed correctly in maintainers/scripts right now, but I don't think this should be the entry-point for OfBorg. Everything in maintainers/scripts should be free to change their interfaces easily, to make the scripts more useful for regular use.

This doesn't need to be figured out in this PR, though. But, we should think about this with #272591 in mind, before taking steps on the OfBorg side.

roberth · 2025-06-21T18:55:55Z

Alternatively, if not expensive to evaluate,

Discovery and producing the mapping should be pretty quick, based on

$ time nix-instantiate -A nixosTests.simple.nodes.machine.meta.maintainers --eval --strict
real	0m1.341s

That is after applying a trivial fix (teams.nextcloud -> .members)
Note that I'm only using nixosTests.simple to produce a NixOS eval conveniently. This returns the test mapping for all of NixOS.

The real cost is in the instantiation of the actual test derivations, which needs to happen locally on the nixpkgs-review machine anyway.

I don't know much about how nixpkgs-review does its instantiations. Ideally they'd be part of the same evaluation, and its expression could call into this PR's logic. That way nixosTests is memoized and no duplicate evaluation work needs to be done.

I can't estimate the cost of the imports graph based mapping now, but it should be cheap, reading only the modules of the test framework and the test itself, not NixOS proper. Up to a dozen?

This provides the needed infrastructure to make tooling like ofborg build the relevant tests, given a set of changed files. Having mandatory CI for modules is not just crucial for DX, but also prerequisite to test-driven expansion of NixOS use cases, such as alternate base module sets. (minimal module list and similar ideas)

This makes it clear that it's a path value literal. We generally prefix ./ even if it's not strictly necessary, because it helps the reader. Co-authored-by: Matt Sturgeon <[email protected]>

Not super quick, but faster than the postgresql case.

_file can be set to a string that does not represent a file path. This is a useful and accepted practice, so it should just work.

Co-authored-by: Wolfgang Walther <[email protected]>

roberth requested review from MattSturgeon and DavHau June 4, 2025 12:55

github-actions bot added 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS 8.has: module (update) This PR changes an existing module in `nixos/` labels Jun 4, 2025

roberth requested a review from infinisil June 4, 2025 12:56

roberth added the 6.topic: developer experience nixpkgs development workflow label Jun 4, 2025

nix-owners bot requested review from RaitoBezarius, Ma27, wolfgangwalther and thoughtpolice June 4, 2025 12:57

roberth mentioned this pull request Jun 4, 2025

nixosMinimal: init - nixos with minimal modules #401751

Open

13 tasks

github-actions bot added 10.rebuild-darwin: 0 This PR does not cause any packages to rebuild on Darwin. 10.rebuild-linux: 1-10 This PR causes between 1 and 10 packages to rebuild on Linux. labels Jun 4, 2025

MattSturgeon reviewed Jun 6, 2025

View reviewed changes

wolfgangwalther reviewed Jun 7, 2025

View reviewed changes

DavHau approved these changes Jun 18, 2025

View reviewed changes

github-actions bot added the 12.approvals: 1 This PR was reviewed and approved by one person. label Jun 18, 2025

wolfgangwalther reviewed Jun 18, 2025

View reviewed changes

roberth mentioned this pull request Jun 18, 2025

No short path literals NixOS/nix#13374

Closed

2 tasks

roberth force-pushed the nixos-meta-tests branch from 054710c to 7b2a135 Compare June 21, 2025 12:35

nix-owners bot requested a review from emilazy June 21, 2025 13:10

nix-owners bot requested review from m1cr0man and arianvp June 21, 2025 13:10

roberth requested a review from a team June 21, 2025 13:56

roberth force-pushed the nixos-meta-tests branch from b66ddf9 to bc73e5b Compare June 21, 2025 17:01

wolfgangwalther reviewed Jun 21, 2025

View reviewed changes

roberth force-pushed the nixos-meta-tests branch from bdb60df to 4aaa2ba Compare June 21, 2025 18:58

roberth mentioned this pull request Jun 21, 2025

lib.filesystem.resolveDefaultNix: init #418824

Merged

13 tasks

nixpkgs-ci bot added the 2.status: merge conflict This PR has merge conflicts with the target branch label Jun 28, 2025

roberth force-pushed the nixos-meta-tests branch from 4aaa2ba to accb3e0 Compare July 7, 2025 07:26

ofborg bot removed the 2.status: merge conflict This PR has merge conflicts with the target branch label Jul 7, 2025

roberth force-pushed the nixos-meta-tests branch from accb3e0 to 997f90b Compare July 7, 2025 07:29

roberth and others added 7 commits July 7, 2025 09:31

maintainers/nixos-tests-for-files.nix: Use ./

97d237b

This makes it clear that it's a path value literal. We generally prefix ./ even if it's not strictly necessary, because it helps the reader. Co-authored-by: Matt Sturgeon <[email protected]>

maintainers/scripts/nixos-tests-for-files.nix: Move and clarify intent

2071cbb

nixos: meta.tests: Handle default.nix abbreviation

52cad0f

nixos: meta.tests: Handle recurseIntoAttrs

77e4fc1

nixos/acme: Add meta.tests

4bd3af5

maintainers/nixos-tests-for-files: Use acme in example

95890e4

Not super quick, but faster than the postgresql case.

roberth force-pushed the nixos-meta-tests branch 2 times, most recently from 1b58dbf to 27d8ee3 Compare July 7, 2025 07:35

roberth and others added 4 commits July 7, 2025 09:37

nixos/meta: Support non-existent _file in meta.tests

ecc7c91

_file can be set to a string that does not represent a file path. This is a useful and accepted practice, so it should just work.

nixos/meta: Dogfood meta.tests

a3c1ac6

nixos/postgresql: Simplify meta.tests

1c7117c

Co-authored-by: Wolfgang Walther <[email protected]>

nixos/nextcloud: Fix meta.maintainers

be42eb8

roberth force-pushed the nixos-meta-tests branch from 27d8ee3 to be42eb8 Compare July 7, 2025 07:37

nixpkgs-ci bot added the 2.status: merge conflict This PR has merge conflicts with the target branch label Jul 26, 2025

	lib.mapAttrsToList (fileName: values: lib.mapAttrs (k: v: { "${fileName}" = v; }) values) relevant
	lib.mapAttrsToList (fileName: lib.mapAttrs (k: v: { "${fileName}" = v; })) relevant

-      filterForNixBuild = paths: lib.concatMap lib.attrValues (lib.attrValues (filter paths));
+      filterForNixBuild = paths: lib.pipe paths [
+        filter
+        builtins.attrValues
+        (builtins.concatMap builtins.attrValues)
+      ];

	filterForNixBuild = paths: lib.concatMap lib.attrValues (lib.attrValues (filter paths));
	filterForNixBuild = paths: lib.collect lib.isDerivation (filter paths);

	default = { ... }: { };
	default = { ... }: { };
	defaultText = lib.literalExpression "{ ... }: { }";

	default = { ... }: { };
	default = _: { };
	defaultText = lib.literalExpression "{ nixosTests }: { }";


		Definitions are tied to the location of the module, so the definition syntax is distinct from the option value format.

		Example definition:

	Example option value:
	Would produce the following option value:

Uh oh!

nixos: Add meta.tests #413892

Are you sure you want to change the base?

nixos: Add meta.tests #413892

Uh oh!

Conversation

roberth commented Jun 4, 2025

Why not infer the mapping automatically?

Things done

Uh oh!

MattSturgeon left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MattSturgeon Jun 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DavHau Jun 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DavHau left a comment

Choose a reason for hiding this comment

Why not infer the mapping automatically?

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wolfgangwalther commented Jun 18, 2025

Uh oh!

DavHau commented Jun 19, 2025

Uh oh!

roberth commented Jun 21, 2025

Uh oh!

roberth commented Jun 21, 2025

Uh oh!

wolfgangwalther commented Jun 21, 2025

Uh oh!

wolfgangwalther commented Jun 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

roberth commented Jun 21, 2025

MattSturgeon Jun 6, 2025 •

edited

Loading

DavHau Jun 18, 2025 •

edited

Loading

wolfgangwalther commented Jun 21, 2025 •

edited

Loading