search

jonringer / flake-v2

What flakes should have been
19 stars 0 forks source link

alternate systems approach? #2

Open nrdxp opened 1 month ago

nrdxp commented 1 month ago

I like where this is going, but the *ForSystems syntax seems uneccesarily verbose. Considering prior art like divnix/nosys, maybe there is a different approach. Nosys uses _ prefixed to an output attribute name to signify that the output is "systemless".

That kind of approach may be too arcane for a proper and core API though, so perhaps we could do something like:

{
  systems = [
    # list of supported systems
  ];
  out.sys = {
    # packages ...
    # whatever else depends on systems
    # maybe `inputs.self.system` is a reference to the current system being evaluated, but only in this scope?
  };
  out.pure = {
    # lib
    # other system independant outputs
  };
  # Placeholder for future output categories
  # This demonstrates the API's flexibility and extensibility
  out.futureCategory = { ... }; # e.g. maybe something explicit for cross-compilation outputs?
}

That way if we want to support schema extension, users don't have to type ForSystem for each new output they introduce, but only once.

I also just changed outputs to out to be as concise as possible, but that is just a stylistic preference of mine, not necessary. I did that to convey clearly to the newcomer that these things are both outputs, just different kinds. But maybe if you want maximum conciseness, that isn't necessary and you could just use sys and pure at the top level, but that risks ambiguity.

It is also possible that the systems attribute would be more appropriate as out.systems instead, or even out.sys.systems, but maybe leaving it at the top-level is more "obvious" to the user that this is a cli level concern?

jonringer commented 1 month ago

I like where this is going, but the *ForSystems syntax seems uneccesarily verbose.

This could also be something like mkPkgs, the name isn't paramount to my main proposal.

I also just changed outputs to out to be as concise as possible, but that is just a stylistic preference of mine, not necessary. I did that to convey clearly to the newcomer that these things are both outputs, just different kinds. But maybe if you want maximum conciseness, that isn't necessary and you could just use sys and pure at the top level, but that risks ambiguity.

Mine is currently a stylistic choice as well. Not really sure the best way to go forward with this.

just use sys and pure at the top level

Yea, but sys sounds like it might be related to a NixOS system... which is a bit misleading, and pure is only obvious if you has a background in functional programming. I would also be fine with something like perSystem = { pkgs }: { ... }; and just keeping the pure outputs as top-level attrs.

It is also possible that the systems attribute would be more appropriate as out.systems instead, or even out.sys.systems, but maybe leaving it at the top-level is more "obvious" to the user that this is a cli level concern?

I don't think the values being return by doing something like getFlake should know of a system.... not sure what this would look like.