[RFC 0123] Flake names

[schuelermine]

[RFC 0123] Flake names

Rendered

[bew]

Wouldn't that prevent the use of alternate names, or having multiple versions of the same flake in the registry?
(I use both)

[schuelermine]

That’s a good point

[schuelermine]

Maybe it’d be a good rule for the global registry, though, but it’d probably be followed anyways, and would only hinder edge-cases

[edolstra]

Note that flakes had a name field but it was removed (80c36d4562af71a90c67b3adb886a1003834890e) because there was no clear use case / semantics. It also raises questions like whether names should be globally unique, and what should happen if they're not.

The RFC mentions discoverability but doesn't really explain how a name attribute helps here. Concretely, what does the name attribute provide to https://search.nixos.org/flakes that the repo URL doesn't already?

See also NixOS/nix#5879 - we thought about bringing back name to be used for default flake output attributes (i.e. packages.<system>.<name> instead of packages.<system>.default).

The derivation that contains the flake’s content is called flake-source-${name} or, if a source control tag (e.g. git tag such as V3) is available, flake-source-${name}-${tag}.

This has the problem described here, namely that it reduces content-addressability by duplicating identical source trees when fetched from different flakes/tags.

[schuelermine]

1. In this case, the clear use case is usage in the derivation name for better UX. In my opinion the name should be entirely decorative or only used for default behaviors.
2. I find non-unique names are a non-issue, they should be disregarded, and are unlikely to be common. Currently, all derivation names are non-unique. Granted, it could confuse people into believing two derivations are of the same flake, but this is still an improvement over not knowing the source at all.
3. I thought the name could be used in the future for a more user-friendly UI. Discoverability of flakes isn’t necessarily helped as the global registry provides it, but it could make flake command usage easier and therefore more discoverable. However, I agree in hindsight that this is a mistaken inclusion, I will strike it from the RFC.
4. I see, the tag is possibly a bad idea. But why is changing the name bad for content addressability? It’s all about coercing derivations with different source expressions but the same result, right?

[JJJollyjim]

Are flakes not still an experimental feature that we're waiting for an RFC to formalise? It seems odd for this to come first.

[schuelermine]

I don’t know how else it would be possible to suggest this feature.

[edolstra]

This RFC is now open for shepherd nominations!

[lheckemann]

@schuelermine maybe you have some people in mind who would be suitable as shepherds? Feel free to nominate them, if so :)

[schuelermine]

@lheckemann I think I’m not familiar enough with the Nix development team & community to confidently nominate anyone in particular. The only people I know are ones I’ve more “seen” than “met”, and I don’t know of their specialties. How would I go about nominating someone?

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/pre-rfc-discussion-making-flakes-discoverable/18834/2

[rehno-lindeque]

Minor use case: flake-help

I use flake.description to print a help message. With this change I could also print flake.name (instead of passing name as another argument).

[jeff-hykin]

Coming from the related nix-discourse (making flakes indexable/discoverable), I'd like to propose simple change to make this forward-compatible and modular.

inputs and outputs are wonderfully elegant/generic names. So tacking on name, description, etc one after another seems like it could easily devolve into a name/pname/version issue, as a bunch of hardcoded edgecases that can never be removed without breaking things.

So, I'd like to propose a static field (name can be anything, I'm just going to call it "static" here)
This would fit in nicely with inputs/outputs and be easy to explain as "flakes have only three top-level keys"

{
    static = {
        name = "anything";
        description = "blah blah blah";
        # arbitrary additional data
        license = "GPLv3";
        keywords = [ "image" "photo" "app" "image-editing" "image-viewing"  "python" ];
        code-source = "https://github.com/some_user/some_repo";
        cve-reports = "";
        bug-reports = "";
        homepage = "";
        icon = "https://";
        latest-sha256 = "";
        bin-names = [ "pip" "python" "python3" ]; # not guaranteed to match outputs, but for searching for a bin-name when package name is unknown
    };
    inputs = {
        nixpkgs = { url = "github:nixos/nixpkgs/nixos-unstable"; };
    };
    outputs = inputs : { };
}

The important aspects being;

1. static contains non-functional data (read "indexable/searchable data" )
2. The structure can be expanded as-needed in a forward-compatible way
3. Unlike inputs or outputs, static can be automated (ex: generated from json) for version bumps and hash changes, which helps solve the unmaintainability problem
4. Rather than must-have requirements, the structure can be flexibly checked against standards. For example:

• nix-search could have its own "baseV1" standard that requires name, description, and license.
  e.g. "Nix Search supports all flakes that comply with the baseV1 standard"
• Lazamar's version search could require having a version string
• NixOS could have an "ApplicationV1" standard that requires additional static fields to be considered an "app" flake
• New standards can build-upon or fork from this without breaking core nix functionality, since there's no guarantee a flake will even have a static field.
• Npm packages could have a requirement for is-npm-package, could require npm-version that follows semver pattern, and could have more strict requirements on name
• Even singular packages could have their own standard such as marking whether something was a LTS release or not

5. This allows systems outside of nix to leverage/understand packages without a full nix evaluation engine

[thufschmitt]

So, I'd like to propose a static field (name can be anything, I'm just going to call it "static" here)

Just bike-shedding on the name (because it’s too tempting), this kinda matches the meta attributes for packages, and I think it could be a good name here too.

(And regardless of the color of the bike, I agree that keeping this things scoped is a good idea, if only to keep the schema tidy)

[jeff-hykin]

So, I'd like to propose a static field (name can be anything, I'm just going to call it "static" here)

Just bike-shedding on the name (because it’s too tempting), this kinda matches the meta attributes for packages, and I think it could be a good name here too.

(And regardless of the color of the bike, I agree that keeping this things scoped is a good idea, if only to keep the schema tidy)

Haha yeah, I actually wanted to call it metadata (and would still like to). I avoided it since nix flake metadata is already a command that returns more just the static field. Maybe this can be meta, and nix flake metadata can be changed since technically what's returned by nix flake metadata is the truly all the static data (I think), including metadata

The idea of static was both to make "non-changing" clear, and from thinking about the whole flake as a function with input args, output value, and static data. Maybe static could even be something passed to the output function.

[roberth]

Suggested change

	- Unique names are useful for the purpose of finding duplicate things caused by diamond dependencies. (E.g. `a -> b -> d1`, `a -> c -> d2`. Without a unique name (`d`), it is not possible to correlate `d1` and `d2` reliably.)

• Most relevant when Flakes: Make avoiding dependency diamonds easier somehow. nix#5570 remains unimplemented. "Userspace" experimentation may yield some insights into solutions for 5570.

[blaggacao]

I had and still have an interest in this and may volunteer to join the shepherds.

May the author reactivate the momentum?

I'd be also interested in exposing self.name since that seems to be missing in small projects where the flake name percolates all through to the binary name.

[schuelermine]

I am still interested in this RFC. This RFC was put into the draft state because I could not produce RFC shepherds. If you’d like to be a shepherd, I can nominate you. I’m not sure how to “reactivate momentum” on this RFC.

[kevincox]

All that it takes to reopen this RFC is to find shepherds. Since we have a nomination it may make sense to bring out of draft and try to find a few more.

[schuelermine]

@blaggacao would you be interested in being a shepherd for this proposal?

[blaggacao]

With https://discourse.nixos.org/t/why-is-there-a-default-overlay-in-flakes/24422/2 in my backpack, I would. 👍

[schuelermine]

I nominate @blaggacao to be a shepherd of this RFC!