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

gnomeExtensions: refactor pnames and derivations headers #86430

Open
wants to merge 1 commit into
base: master
from

Conversation

@firmero
Copy link
Contributor

firmero commented May 1, 2020

Motivation for this change

Refactoring:

  • use unstable in version field instead of pname
  • pnames have prefix gnome-shell-extension (except GNOME Shell integration)
Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.
@worldofpeace worldofpeace requested review from jtojnar and NixOS/gnome and removed request for jtojnar May 1, 2020
@hedning
Copy link
Contributor

hedning commented May 1, 2020

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

@firmero
Copy link
Contributor Author

firmero commented May 1, 2020

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

@firmero
Copy link
Contributor Author

firmero commented May 1, 2020

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.

@hedning
hedning approved these changes May 1, 2020
Copy link
Contributor

hedning left a comment

Yep, that makes sense :)

@worldofpeace
Copy link
Member

worldofpeace commented May 1, 2020

I believe we shouldn't actually do this #68518

@firmero
Copy link
Contributor Author

firmero commented May 2, 2020

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.

@worldofpeace
Copy link
Member

worldofpeace commented May 2, 2020

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.

@jtojnar
Copy link
Contributor

jtojnar commented May 2, 2020

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.

@firmero
Copy link
Contributor Author

firmero commented May 4, 2020

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.

@romildo
Copy link
Contributor

romildo commented May 4, 2020

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+

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.