Sounds reasonable, though can't quite remember what's the convention with the unstable bit (ie. should it be part of the name or version).

Sounds reasonable, though can't quite remember what's the convention with the unstable bit (ie. should it be part of the name or version).

Grepping on repo:

grep -rw "unstable" | grep "pname =" | wc -l
gives me 108

grep -rw "unstable" | grep "version =" | wc -l
gives me 266

And also it makes it simpler in the future to switch to release tags (e.g. current upstream doesn't provide yet). Then we need just update version field instead of both pname and version. To user it doesn't make any difference, i think, because he/she sees package name as concatenation of pname and version field.

I believe we shouldn't actually do this #68518

I am confused. So, there is no official guideline for package naming which cover that problem yet? I found only #sec-package-naming from Nixpkgs Users and Contributors Guide.

Here's the main reason unstable should be in pname.

nix-repl> name = "gnome-shell-extension-caffeine-unstable-2020-03-13"
nix-repl> builtins.parseDrvName name
{ name = "gnome-shell-extension-caffeine-unstable"; version = "2020-03-13"; }

Notice how unstable isn't part of version when parsed by nix.
So unstable should be in pname then. I'm sure @jtojnar could explain this in more depth, semantics wise, but in a general sense this is a strong reason to not do this.

Yes that is an argument for having it in name but I consider parseDrvName a hack (either Nix cares about package versions, and then it should support version attribute, or it does not, and versions should be handled only in Nixpkgs and builtins.parseDrvName removed, see https://github.com/NixOS/nixos-homepage/issues/306#issuecomment-605781929 for more discussion) so maybe we should not worry about it too much.

Until this issue is resolved, I am uncertain which variant should we promote. Maybe we can side-step it by recommending 2020-03-13-unstable in versions.

So, it is ok for now to use 2020-03-13-unstable in the version?

I also don't know how to cope with schema of an extension. Can be copied to /share/gsettings-schemas/$extension/glib-2.0/schemas using glib.makeSchemaPath to make schema global visible e.g. for dconf-editor and similar utilities (pull#discussion). Some recommendation?

Also nix files for gnome extensions doesn't seem to me consistent (e.g. prefix of pname is not always gnome-shell-extension, version field via let, and so on) and for novice who wants to take an inspiration and contribute it is not so kind.

Until this issue is resolved, I am uncertain which variant should we promote. Maybe we can side-step it by recommending 2020-03-13-unstable in versions.

1+

I marked this as stale due to inactivity. → More info

Thank you for your work on this. A lot has happened since you opened, please start anew (I don't think a rebase in the git sense would work) on top of master.

• Unless there is a distinct "stable" packaging, "unstable" should indeed be removed from the pname. I think only tilinggnome is affected
• Unstable versions should start with the unstable- prefix. However, a lot of extensions have moved towards release numbers and a lot of packaged extensions have been removed, so a lot less are affected than before
• The -extension part in pname has already been done in gnomeExtensions: normalize pnames #124295

Obsoleted by 2de33b7 in #137131.