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.
As mentioned in the previous commit, we don't have a use case for
this in flake-parts yet, as far as I'm aware. It can be exposed
when we do have a concrete use case where it is needed.
The difference is that moduleLocation is "guaranteed" reliable data,
whereas errorLocation is the best choice for error messages in the core.
moduleLocation is suitable for the module key attribute.
errorLocation is best for the *ROOT* module _file attribute.
Initially I applied errorLocation in too many places. It is only needed
when the flake output attribute names are strict in it.
To avoid confusion, I'm not exposing errorLocation to the modules, until
we have a concrete use case for it.
171: Add more docs r=roberth a=woile
This PR adds the following:
- an examples folder
- an example for devShell
- templates are no longer marked as examples, now there are templates and examples avoiding confusion
#170
Co-authored-by: Santiago Fraire <santiwilly@gmail.com>
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
172: Add aarch64-linux and x86_64-darwin systems to the default template r=roberth a=sempruijs
The default template had only aarch64-darwin and x86-64-linux systems. I've added aarch linux and x86-64 darwin
Co-authored-by: sempruijs <sem@pruijs.net>
