kana: init at 1.4

[Aleksanaa]

Description of changes

just for fun

./result/
├── bin
│   └── kana
└── share
    ├── applications
    │   └── com.felipekinoshita.Kana.desktop
    ├── glib-2.0
    ├── gsettings-schemas
    │   └── kana-1.4
    │       └── glib-2.0
    │           └── schemas
    │               ├── com.felipekinoshita.Kana.gschema.xml
    │               └── gschemas.compiled
    ├── icons
    │   └── hicolor
    │       ├── scalable
    │       │   └── apps
    │       │       └── com.felipekinoshita.Kana.svg
    │       └── symbolic
    │           └── apps
    │               └── com.felipekinoshita.Kana-symbolic.svg
    ├── kana
    │   └── resources.gresource
    └── metainfo
        └── com.felipekinoshita.Kana.metainfo.xml

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[AndersonTorres]

Suggested change

	rev = "v${version}";
	rev = "v${finalAttrs.version}";

[lolbinarycat]

what is the actual advantage of this? it's not like overriding version will work properly, since all the fetchers are fixed-output

in fact, this could even cause a derivation to build fine on one system, but fail on another (i've had this happen when updating packages and forgetting to invalidate the source hash, this could be extremely confusing to less technical users who haven't touched the inside of nixpkgs)

[AndersonTorres]

what is the actual advantage of this?

Get rid of rec.

[lolbinarycat]

but the only problem with rec that page mentions is the possibility for infinite recursion, which is equally possible with the finalAttrs pattern.

i asked what the advantage of getting rid of rec is, and you gave me quite a recursive answer.

[eclairevoyant]

finalAttrs is preferable in cases where attributes of the derivation are actually used within the derivation - here the only places where it's used are in src and cargoDeps, which doesn't really save much effort when someone goes to override.

And this specific usage is at least somewhat contentious: see #293452 (comment)

I do not consider this worth blocking a review on.

[AndersonTorres]

Suggested change

	meta = with lib; {
	meta = {

Nested with is bad.

[Aleksanaa]

I know nested with is bad, but the only thing that is nested here is the name of the maintainer, while writing "lib" everywhere is very ugly. And this is almost a convention in nixpkgs.

[AndersonTorres]

And this is almost a convention in nixpkgs.

1. You was complaining about finalAttrs not being written convention or enforced guideline, but now you are arguing about with lib; being a consuetudinary convention and enforcing it? Please be consistent.
2. Tracking issue: remove overuses of with lib; #208242

[Aleksanaa]

You was complaining about finalAttrs not being written convention or enforced guideline, but now you are arguing about with lib; being a consuetudinary convention and enforcing it? Please be consistent.

No, my request was consistent actually: I'm requesting a formal discussion about whether a particular format or feature should be adopted, and a documentation change indicating the best practice to follow (I know there is one waiting to be merged now). (And, if possible, automatically suggested changes by CI.) Before that, I'm always going to follow the common practice in Nixpkgs, which I've always found clean and easy, but I'm not going to debate if that's the best practice.

I have long found that following some suggestions of newer modifications can be a problem: for example, when adding environment variables, although some committers think that we should always prefer env.XXX, there are also commiters suggesting me to remove the leading env. This concern also affects my opinion of this suggested change, because I have added more than 30 packages in the past year, but this is the first time I have received this request, and after receiving this request, my other PRs submitted at the same time still passed the review. So I doubt the progress of committers' discussions on these issues.

Besides that, yes, the changes are good to go and applying them doesn't seem to introduce new problems for me.

[AndersonTorres]

No, my request was consistent actually: I'm requesting a formal discussion about whether a particular format or feature should be adopted, and a documentation change indicating the best practice to follow (I know there is one waiting to be merged now).

Since nix.dev is NixOS-blessed documentation, their best pratices advices are authoritative, even if not vinculative.
Given the above,

• finalAttrs gets rid of rec, and getting rid of rec is one of best practices
  • indeed finalAttrs is documented in the NixOS stdenv docs, have you read about it?
• no nested with aligns with avoiding with

I have long found that following some suggestions of newer modifications can be a problem: for example, when adding environment variables, although some committers think that we should always prefer env.XXX, there are also commiters suggesting me to remove the leading env.

Currently, attributes not recognized by (say) stdenv.mkDerivation are treated as environment vars to the shell.

It can bring problematic issues, like "oh, i wrote propBuildInputs instead of propagatedBuildInputs, and this bug goes undetected".

By using env you are explicitly saying this is an environment variable.

Indeed this is one of examples given by dream2nix project to use NixOS-like modules:

https://nix-community.github.io/dream2nix/modules.html

[eclairevoyant]

Since nix.dev is NixOS-blessed documentation, their best pratices advices are authoritative

Nothing in the nix.dev link indicates that meta = with lib; is unacceptable - that's a separate case from with lib; at the top of a file.

I do not consider this worth blocking a review on.

attributes not recognized by (say) stdenv.mkDerivation are treated as environment vars to the shell

Nit: basically all attributes are treated as envvars.

By using env you are explicitly saying this is an environment variable.

Agreed, the point of env is to be explicit about intention. If an attribute's purpose is to be used as an envvar and not a builder arg, then it should use env.

[AndersonTorres]

Nothing in the nix.dev link indicates that meta = with lib; is unacceptable - that's a separate case from with lib; at the top of a file.

with lib; around meta set invariably bring the issue of nested with.
The most typical usage is something like

meta = with lib; {
   maintainers = with maintainers; . . . ;
   platforms = with platforms; . . . ;
}

And the nix.dev link says, among other things:

When more than one with used, it’s not clear anymore where the names are coming from.

Therefore, I believe that avoiding instances of meta = with lib; are worth removing and is in line with the arguments of that link.

Further, removing nested with and restricting with to single-line expressions is more manageable than removing with unconditionally, therefore being a good compromise.

I do not consider this worth blocking a review on.

Neither I.
But I will blame GitHub: it has no such a thing as a "yellow" unblocking review.
On the other hand, I have no power to block a PR indefinitely.

[AndersonTorres]

Suggested change

	maintainers = with maintainers; [ aleksana ];
	platforms = platforms.unix;
	maintainers = with lib.maintainers; [ aleksana ];
	platforms = lib.platforms.unix;

[AndersonTorres]

Suggested change

	}
	})

[KiaraGrouwstra]

tested, the built application works fine :)

[AndersonTorres]

Break it on Darwin.

[eclairevoyant]

Builds and runs. Thanks for the contribution!

Regarding the other reviewer feedback:

• There's currently no consensus to remove meta = with lib;
• finalAttrs without some usage of said attrs outside of src or other FOD-related construct is also contentious
• If we establish consensus, this can be addressed with a treewide change rather than blocking a package PR over it

[eclairevoyant]

finalAttrs is preferable in cases where attributes of the derivation are actually used within the derivation - here the only places where it's used are in src and cargoDeps, which doesn't really save much effort when someone goes to override.

And this specific usage is at least somewhat contentious: see #293452 (comment)

I do not consider this worth blocking a review on.

[eclairevoyant]

Since nix.dev is NixOS-blessed documentation, their best pratices advices are authoritative

Nothing in the nix.dev link indicates that meta = with lib; is unacceptable - that's a separate case from with lib; at the top of a file.

I do not consider this worth blocking a review on.

attributes not recognized by (say) stdenv.mkDerivation are treated as environment vars to the shell

Nit: basically all attributes are treated as envvars.

By using env you are explicitly saying this is an environment variable.

Agreed, the point of env is to be explicit about intention. If an attribute's purpose is to be used as an envvar and not a builder arg, then it should use env.