From 951506084364021a4b82114841eb6bb6d0eb869a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Anselm=20Sch=C3=BCler?= Date: Sat, 12 Mar 2022 22:04:30 +0100 Subject: [PATCH] =?UTF-8?q?=F0=9F=93=82=20Add=20RFC=20=E2=80=9Cflake-names?= =?UTF-8?q?=E2=80=9D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 0000-flake-names.md | 54 +++++++++++++++++++++++++++++++++++++++++ 0000-template.md | 58 --------------------------------------------- 2 files changed, 54 insertions(+), 58 deletions(-) create mode 100644 0000-flake-names.md delete mode 100644 0000-template.md diff --git a/0000-flake-names.md b/0000-flake-names.md new file mode 100644 index 0000000..178d1eb --- /dev/null +++ b/0000-flake-names.md @@ -0,0 +1,54 @@ +--- +feature: flake-names +start-date: 2022-03-12 +author: Anselm Schüler +co-authors: None +shepherd-team: None +shepherd-leader: None +related-issues: None +--- + +# Summary +[summary]: #summary + +Flakes can declare the field `name`. +It represents the name of the flake. +The derivations for a flake are no longer called `source`, but use the flake name. + +# Motivation +[motivation]: #motivation + +Flake-centric workflows often end up with a lot of derivations named “source”, and it’s difficult to navigate this. +Also, the discoverability and usability of flakes needs to be improved. Current commands mostly show technical information. This would be a step in the right direction. + +# Detailed design +[design]: #detailed-design + +A new supported property for flakes is introduced, `name`. +Running `nix flake metadata` on a flake that declares this field displays it at the top. +The derivation that contains the flake’s content is called `flake-source-${name}` or, if a short revision identifier is available, `flake-source-${name}-${shortRev}`. + +# Examples and Interactions +[examples-and-interactions]: #examples-and-interactions + +A flake that is in the registry should have its name match the registry identifier. + +# Drawbacks +[drawbacks]: #drawbacks + +This may cause clutter and additional maintenance. + +# Alternatives +[alternatives]: #alternatives + +Flake names could be handled entirely through outside means, with things like the global registry merely pointing to flakes under names. + +# Unresolved questions +[unresolved]: #unresolved-questions + +The name scheme could be changed. `flake-source-${name}-${shortRev}` could be too long. + +# Future work +[future]: #future-work + +Flake discoverability and usability needs to be improved. diff --git a/0000-template.md b/0000-template.md deleted file mode 100644 index 43569cf..0000000 --- a/0000-template.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -feature: (fill me in with a unique ident, my_awesome_feature) -start-date: (fill me in with today's date, YYYY-MM-DD) -author: (name of the main author) -co-authors: (find a buddy later to help out with the RFC) -shepherd-team: (names, to be nominated and accepted by RFC steering committee) -shepherd-leader: (name to be appointed by RFC steering committee) -related-issues: (will contain links to implementation PRs) ---- - -# Summary -[summary]: #summary - -One paragraph explanation of the feature. - -# Motivation -[motivation]: #motivation - -Why are we doing this? What use cases does it support? What is the expected -outcome? - -# Detailed design -[design]: #detailed-design - -This is the core, normative part of the RFC. Explain the design in enough -detail for somebody familiar with the ecosystem to understand, and implement. -This should get into specifics and corner-cases. Yet, this section should also -be terse, avoiding redundancy even at the cost of clarity. - -# Examples and Interactions -[examples-and-interactions]: #examples-and-interactions - -This section illustrates the detailed design. This section should clarify all -confusion the reader has from the previous sections. It is especially important -to counterbalance the desired terseness of the detailed design; if you feel -your detailed design is rudely short, consider making this section longer -instead. - -# Drawbacks -[drawbacks]: #drawbacks - -Why should we *not* do this? - -# Alternatives -[alternatives]: #alternatives - -What other designs have been considered? What is the impact of not doing this? - -# Unresolved questions -[unresolved]: #unresolved-questions - -What parts of the design are still TBD or unknowns? - -# Future work -[future]: #future-work - -What future work, if any, would be implied or impacted by this feature -without being directly part of the work?