Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC 0105] Nix flake labels #105

Closed
wants to merge 4 commits into from
Closed

Conversation

bryanhonof
Copy link
Member

@bryanhonof bryanhonof commented Sep 3, 2021

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

# Detailed design
[design]: #detailed-design

The `tags` attribute in a flake should NOT be mandatory, but optional. It is
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@bryanhonof bryanhonof changed the title [RFC 0103] Nix flake tags [RFC 0103] Nix flake labels Sep 8, 2021
@spacekookie spacekookie changed the title [RFC 0103] Nix flake labels [RFC 0105] Nix flake labels Sep 9, 2021
@spacekookie spacekookie changed the title [RFC 0105] Nix flake labels [RFC 105] Nix flake labels Sep 9, 2021
Copy link

@gytis-ivaskevicius gytis-ivaskevicius left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

edolstra commented Sep 9, 2021

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?).

@edolstra edolstra changed the title [RFC 105] Nix flake labels [RFC 0105] Nix flake labels Sep 9, 2021
@Mic92 Mic92 added status: open for nominations Open for shepherding team nominations and removed status: new labels Sep 9, 2021
@gytis-ivaskevicius
Copy link

@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
Copy link
Contributor

tomberek commented Sep 9, 2021

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
Copy link

lucc commented Sep 14, 2021

@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
Copy link

lucc commented Sep 14, 2021

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
Copy link
Member Author

bryanhonof commented Sep 16, 2021

@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
Copy link
Member

andir commented Sep 16, 2021

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
Copy link
Member

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

@lheckemann
Copy link
Member

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
Copy link

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
Copy link
Contributor

blaggacao commented Oct 18, 2021

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
Copy link
Member

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

@bryanhonof bryanhonof closed this Aug 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.