sharing model

[blaggacao]

flake-utils-plus/systemFlake.nix

Line 5 in 51cb739

, sharedExtraArgs ? { inherit inputs; }

What is the rational of defaulting to inputs rather than have people make use of inputs in their top level flake?

The inputs thought model as extraArgs neglects the "receptionist" thought model of the flake.nix.
I think flake.nix as receptionist is an important feature of the distributed future of flakes, "to show new guests around": Hans visit's James' repo on github. flake.nix gives him the map and tells at least the outline of the story.

What cases cannot be covered by receiving inputs in flake.nix and dispatching eg overlays via input.otherflake.overlay or inputs.otherflake.nixosModules?

I think it was not an afterthought to make those two public static api of flakes themselves, in the first place by the designers of flakes.

One thing that comes to my mind ...

In a sharing model based on overlay it is not always trivial to pull in the following:

let
   bob = {
     kakoune = {};
     chrome = {};
   };
   alice = {
     kakoune = {};
     chrome = {};
   };
in
[
  bob.kakoune
  alice.chrome
]

flake-utils.lib.simpleFlake solves this by implicitly doing a namespacing of overlays.

Should we really go down that route and just globally pass through inputs, by default?
→ What this does not do is expose and promote encapsulation via the top level flake api.

/cc @Pacman99 @nrdxp

[gytis-ivaskevicius]

Just to clarify, why is it passed globally like so:

1. Input can be any git repo which is very convenient for package sources
2. Usually people implement it as inputs instead of { inherit inputs; } (if that makes sense) - this creates an issue of input name conflicts
3. Currently fup uses it to implement a pretty dam cool repl and to auto-populate nix.registry

[blaggacao]

Nice!

ad 1. devos implements this feature as srcs coming from pkgs/flake.nix

ad 3. No interference with sharing model, here.

ad. 2. Are there known use cases where inputs bring additional attributes that cannot be captured via sharedModules & sharedOverlays?

[gytis-ivaskevicius]

inputs is just an attribute - there is no problem passing it manually using sharedModules / sharedOverlays but that just adds additional complexity to the user, and really - I do not see any downsides in passing it automagically

[blaggacao]

If I had a crazy idea and needed a package from inputs somewhere and did:

{
  nativeBuildInputs = [
    inputs.some.packages.${pkgs.stdenv.system}.mypkgs
  ];
}

Does this have potential serious odds?

It is a somewhat hyper-namespaced alternative to namespacing pkgs as simpleFlake does?

To understand my concerns, one has to understand that I'm mainly concerned with the sharing model, not if it "works for me". Nixos sharing model has potential, since traditionally everyone cooked their own soup and users where just proficient enough to plug things together. But that model clearly fails for less proficient users, so I'm trying to figure out what is it that we should strongly encourage and strongly discourage so that people present a nice sharing interface effortlessly, by default.

Currently, I just want to put that egg on the table. I have no clear vision or concept, yet, myself.

[blaggacao]

Maybe we have indeed to fall back to pkgs namespacing to unbreak the "blessed" (overlay) sharing model.
If we can make the built-in model work, people might not be in need of a workaround that clutters best practices.

Problem:

alice.pkgs = {
    kakoune = {};
    chrome = {};
};
bob.pkgs = {
    kakoune = {};
    chrome = {};
};

overlays = [ inputs.overlays.alice inputs.overlays.bob ];

# How do I use alice's `kakoune`?

[gytis-ivaskevicius]

I've seen users do inputs.some.packages.${pkgs.stdenv.system}.mypkgs and I am not a fan of this approach. In this particular case, I recommend just defining a custom overlay and using it

As for sharing issue - this is what I do:
My Overlays definition
Normal packages are named properly (like lightcord), packages that I wrapped/customized are prefixed with g-. This means that other people can import my overlay without worrying about conflicts.

Also, may I add that I am exporting packages which are just overlays overlayed on top of nixpkgs (if that makes sense) Flake implementation

In case overlay overwrites something like in the example above - this solution pops into my mind:

final: prev: {
   alice = inputs.alice.overlay final prev;
}

this way we can install alice's kakoune by simply typing pkgs.alice.kakoune

[blaggacao]

Nice context you give!

final: prev: {
   alice = inputs.alice.overlay final prev;
}

Unfortunately, if alice also defines a module using one of her packages, we would break that, if we also tried to use it.

[gytis-ivaskevicius]

I don't think that I caught the issue. Can you elaborate on the use case that this does not cover?

[blaggacao]

So we also do:

sharedModules = [ inputs.alice.nixosModules."modules/services/development/kakoune" ]

within alice's world, this modules access pkgs.kakoune (instead of pkgs.alice.kakoune as defined by inputs.alice.overlay).

It's a non-sensical module that starts cage service and launches kakoune, btw. (alice only allows herself to code 😉).

This module also depends on alice's coustom kakoune, but imported as suggested, it would invoke our pkgs.kakoune (instead of pkgs.alice.kakoune as defined by inputs.alice.overlay), hence we have broken it.

[blaggacao]

Currently, fup does not implement a minimum consensus default on how to export packages, it expects the user to provide a packageBuilder, instead.

On the other hand, it might promote the overall sharing model.between fup uswrs, if fup would adopt sane packges outputs by defult.

To lay the foundations on package filtering, I opened an upstream issue numtide/flake-utils#27

For fup, the task would be to re-export overlays per system as packages, similar to what simpleFlake does.

[blaggacao]

So now there is a +- usable version packagesFromOverlaysBuilderConstructor & overlaysFromChannelsExporter in staging, which closes this issue.

There is also modulesFromList exporter which expands the sharing model to modules.

None of them are currently "activated" by default. We could discuss doing soe once they are completely stable and validated.