The alternative would have been to try and make this not an evaluation error,
but that would cause problems.
Idea: use filterAttrs to construct an attrset "inputFlakes". This would be
bad because it requires that we evaluate all inputs, just to see whether
they're flakes or not.
If Nix were to provide this metadata independently, which it could do
very efficiently, we still ought to wonder what's the purpose of
eliding those attributes. The only ways you'll encounter this
exception in `inputs'.<broken>` is by either
- making a mistake, in which case the error message is great
- or traversing all inputs, which nobody should do.
See https://flake.parts/best-practices-for-module-writing#do-not-traverse-inputs
Other idea: return *something empty*. This avoids the strictness
problem above, but still optimizes for the wrong use case.
Ultimately though, attribute transposition should not be needed at all,
but this project is largely dependent on the implicit schema imposed by Nix.
Currently when trying to access packages from input flakes for a system that isn't supported by that flake, the error is not very conclusive.
It costed me at least an hour to grasp this. Now putting in this error message to prevent others from falling into the same trap.
Example:
```
error: `self` (without `'`) is not a `perSystem` module argument, but a
module argument of the top level config.
The following is an example usage of `self`. Note that its binding
is in the `top` parameter list, which is declared by the top level module
rather than the `perSystem` module.
top@{ config, lib, self, ... }: {
perSystem = { config, self', ... }: {
# in scope here:
# - self
# - self'
# - config (of perSystem)
# - top.config (note the `top@` pattern)
};
}
```
The `anything` type is too strict, because it uses `attrsOf`
internally, filtering out `mkIf` attrs and therefore evaluating
attribute values when only the names would be needed.
Furthermore, it is not safe to make assumptions about the objects
in legacyPackages, because while most attributes contain packages
or package sets, anything is allowed, so we don't know for sure how
to merge.
Fixes#52
