[RFC 0105] Nix flake labels

[bryanhonof]

Currently a flake's only way to explain what it is that it contains is trough its description. Having labels could aid the end-user determine what a flake contains on an higher level.

Rendered

[jonringer]

since flakes are heavily coupled to git, and tag is already a well-defined term when referring to version control, maybe the use of label would be more appropriate?

Otherwise I could see a scenario where someone says, "I cut a [git] tag for the product, make sure to update your [flake-referenced git] tags in your flakes. I also added another [flake] tag, to help with discoverability"

[bryanhonof]

That's a good comment, I hadn't thought about this myself. I'll make the edit when I get back behind my PC.

[gytis-ivaskevicius]

Few thoughts:

I find it funny that we got flakes definition change RFC before the introduction of flakes themselves RFC (Does this change even need to be an RFC?)

s/tag/label/g (Not everything has been renamed yet)

I very much do like the idea of tags as such:

• machine-learning
• system-config
• messaging
• containers
• cloud
• home-manager-config
• project-xyz-packages

But consider (just consider) replacing examples like python3/c-plus-plus due to them being oddly specific and summarizing derivation itself instead of the flake.

Sidenote:
It would be useful if we could evaluate flakes repository information (like repository name/owner) from within configuration. But this is probably out of scope for this RFC

[edolstra]

The main problem with adding tags is that flakes are decentralized and uncurated. Without a central authority to organize tags, they're likely to become a mess where nobody agrees on what the preferred tag names are for a particular topic (e.g. do you use c++ or c-plus-plus), or what the exact semantics are (e.g. does python mean any software written in Python, or a Python module?).

[gytis-ivaskevicius]

@edolstra I don't think that there are any problems with it being decentralized and uncurated. The idea of labels/tags is definitely not new and we can take a look at other platforms for reference:

• twitter
• Google Ads
• SEO stuff
• Article websites (like medium.com)
• Photo galleries (like deviantart.com)

What they all have in common are non-standartized tags.
One may ask how come it works well for sites as such? The answer is simple - due to authors themselves having an interest in tagging their content in an easily discoverable manner.

BUT, I since previous comment I gave it more thought and I think this should be approached differently:
Pretty much all flakes are stored on Github or Gitlab, these platforms have labeling functionalities of their own.
How about instead of implementing this as part of the flakes we modify search.nixos.org to query GitHub/GitLab APIs and grab tags/description/license/releases/whatever from there instead.

[tomberek]

Part of the question here would be if it helps discoverability. Integration with nixos-search? Otherwise the name and description become de-facto search terms: https://github.com/NixOS/nixos-search/blob/af3b49421784fa557b90acffef08168d43d2a699/flake-info/src/elastic.rs#L17-L21

[lucc]

@gytis-ivaskevicius & @edolstra python's pip also has labels or tags. They just call it classifiers: https://pypi.org/classifiers/
They provide a long list of standard(?) classifiers.

I have not much experience apart from adding some to my python project for good measure. But maybe there is something to learn from the python guys here. They have a short section about it in a PEP:
https://www.python.org/dev/peps/pep-0301/#distutils-trove-classification

I did not look for any further info (blogs, email lists) to see how their experience was after some time.

[lucc]

I thought about what I wanted to say before again, the idea is this:

• If we want we can implement a fixed set of predefined labels in nix itself (@edolstra nix would serve as a centralized place to define and manage the standard labels, this is the only thing the decentralized flakes can rely on)
• any string could be used as a label (not just the defined standard labels); they do not concern evaluation of the flake
• nix flake check could complain about non standard labels

[bryanhonof]

@lucc

If we want we can implement a fixed set of predefined labels in nix itself
any string could be used as a label (not just the defined standard labels); they do not concern evaluation of the flake

I agree that it's not a good idea to enforce a predefined set of labels. However, I do think it'd be a good idea to have a sane set of default labels, or rather, recommended naming schemes. We could do this by providing a set of already well-known labels, just like the meta.licenses attribute works right now in the mkDerivation function. But don't keep the end-user from creating their own.

---

@gytis-ivaskevicius

BUT, I since previous comment I gave it more thought and I think this should be approached differently:
Pretty much all flakes are stored on Github or Gitlab, these platforms have labeling functionalities of their own.
How about instead of implementing this as part of the flakes we modify search.nixos.org to query GitHub/GitLab APIs and grab tags/description/license/releases/whatever from there instead.

I thought about this as well, but I came to the conclusion that it'd be extremely annoying to maintain this way. Sure, git{hub,lab} support this at the moment, but there's examples of forges that don't. I think flakes should be self-describing, and the description attribute is already a good idea, but it might not be enough.

I'm also thinking, would it perhaps make sense to think about a meta attribute for flakes, just as mkDerivation has?

---

@edolstra

The main problem with adding tags is that flakes are decentralized and uncurated. Without a central authority to organize tags, they're likely to become a mess where nobody agrees on what the preferred tag names are for a particular topic (e.g. do you use c++ or c-plus-plus), or what the exact semantics are (e.g. does python mean any software written in Python, or a Python module?).

I agree with @gytis-ivaskevicius on this one. I think, over time, people will figure out what works best. And if we provide a sane set of defaults, that's already a bit of the burden of organising it to improve search-ability.

---

@tomberek

Part of the question here would be if it helps discoverability. Integration with nixos-search? Otherwise the name and description become de-facto search terms: https://github.com/NixOS/nixos-search/blob/af3b49421784fa557b90acffef08168d43d2a699/flake-info/src/elastic.rs#L17-L21

This is something I'm willing to research a bit about. But I can't give an answer on this right now.

---

P.S. Sorry for replying to multiple people in the same comment.

[andir]

Just a thought: How about making tags part of the registry entry of flakes? That way the operator of the registry can apply whatever tags that they seem correct. When you submit your flake for addition into a registry you can have a discussion with that group of people about what tags they use and which ones you'd want to add.

The actual flake wouldn't require any amount of changes and everyone can enforce the guidelines they like to follow for their registry.

[AndersonTorres]

Flakes have such a thing as a meta attribute? Because those meta things as description or labels look a bit meta.

[lheckemann]

This RFC is open for nominations, anyone who has ideas who would make a good shepherd (including themselves) is welcome to nominate them :)

[gytis-ivaskevicius]

Sure, git{hub,lab} support this at the moment, but there's examples of forges that don't. I think flakes should be self-describing, and the description attribute is already a good idea, but it might not be enough.

Self-hosted GitHub alternatives are not going to get included in nixos-search either way, which raises another question - do flake labels bring any value in any other use case aside from search engine integration? 🤔

[blaggacao]

I want to add to @edolstra 's commemt & @gytis-ivaskevicius reply:

Decentralized tags work in github, ..., because while the creation of a tag is decentralized, the semantic of an existing tag is not in isolation:

When you tag something, you discover other tagged projects immediately.

This very short feedback loop ensures eventual auto-curation.

Flakes are created in isolation. The feedback loop to discover other projects with the same tag can be much larger.

A larger feedback loop leads to less efficient auto-curation.

Hence, this RFC is not a no-brainer and I think we should start with @andir 's suggestion to leave curation to registry operators.

Based on that, we can let the ecosystem mature and come back to this suggestion with more data & experiences.

[spacekookie]

This RFC is open for nominations btw! Feel free to nominate anyone you think would be a good shepherd for this RFC (including yourself)