📂 Add RFC “flake-names”

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.

0000-template.md

@@ -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?