Subdirectory for "miscellaneous" outputs

[jzbor]

Is your feature request related to a problem? Please describe.

There are many kinds of third-party output attributes, which blueprint has no support for. It does not make sense to integrate each one of those attribute types, but it would still me nice to give users an escape hatch.

Describe the solution you'd like

I currently have a /misc subdirectory in my flake for non-standardized outputs and overrides for blueprint. /misc/default.nix is called with the flake inputs as a parameter and joined with blueprint's outputs via recursiveUpdate: https://github.com/jzbor/nixos-config/blob/773c6f52fc789fbbe3f9a50299aaa6ae4a730600/flake.nix#L55

I think this is quite a nice solution, as it gives non-standardized outputs their own directory. It keeps the flake clean, yet still extensible.

Describe alternatives you've considered

I have not considered any alternatives yet, of course you could just leave solutions like this up to the user.

Additional context

See also #74

[phaer]

Can you elaborate what the relation to #74 is here? Did you mean your feature-request for nix-on-droid in #73?

Not a huge fan of that proposal myself: I think merging blueprints outputs with custom ones, as you did, should work well enough for users wanting something like this?
On the hand "misc" runs against the spirit of blueprints opinionated design imo.

[JumpIn-Git]

this isnt needed, see my flake:

  outputs = {
    inputs,
    blueprint,
  }:
    blueprint {inherit inputs;}
    // {
      overlays = import ./overlays {inherit inputs;};
    };

[jzbor]

this isnt needed, see my flake:

This is pretty much the workaround I am using right now (see the link), except for more deeply nested attributes recursiveUpdate is necessary instead of a regular update operator.

Can you elaborate what the relation to #74 is here? Did you mean your feature-request for nix-on-droid in #73?

I was kinda thinking of both. It would make workarounds like the one I applied to #74 easier and more streamlined by giving them an explicit place in the blueprint flake. It would also make adding stuff like nix-on-droid (#73) easier. I currently have both in my /misc (as seen in the link above).

I don't immediately see, why this goes against an opinionated design. This directory would be primarily about users wishing to add stuff on top of blueprint, not to circumvent blueprint, but rather to make it work more easily with non-supported outputs. While nix-on-droid was the only one I had in my repo there are also other non-standardized outputs (e.g. deploy for deploy-rs). In order to provide a good, opinionated template for flakes, without having to introduce breaking changes down the road it might be good to have this /misc-directory as a testing ground as well as for users wishing to switch to blueprint, without giving up some of their flakes functionality or hacking their way around blueprints design.

I do think the (opinionated) design of blueprint is really nice, which is why I would appreciate if it would also give this escape hatch for extensibility. At they end of the day I don't care that much if it gets mainlined or not. I am fine with just adding this to my projects the way I do right now. Just thought this would be a pattern which others might profit from as well.

[zimbatm]

Having a place for extension would make it easier to say no to use-cases not core to Blueprint. Right now nix/default.nix is starting to get a bit fat because we're taking on valid use-cases (which is more important). I'd like to keep the core simple.

The rework is going to require tearing nix/default.nix apart. Probably a fixpoint. Ideally I would like to find an interface to make blueprint flakes pluggable instead of taking the /misc approach (I know it sounds vague, that's all I have rn).

TBD

[phaer]

I don't immediately see, why this goes against an opinionated design. This directory would be primarily about users wishing to add stuff on top of blueprint, not to circumvent blueprint, but rather to make it work more easily with non-supported outputs.

Well by virtue of containing "miscellanous" stuff, which seems like the opposite of something opinionated, no? Or to reverse the question: What would a directory like that give you that the current implementation does not allow you? The example in your flake looks like clean, minimal code to me, not necessarily something I'd call a "workaround" personally.

If we add support for nix-on-droid, I think something like hosts/$name/droid-configuration.nix akin to darwin-configuration.nix might be preferable.