[Tracking] Review package examples from manual

[davidak]

Issue description

We teach packaging using examples, but i think these examples don't follow latest best practices.

https://nixos.org/manual/nixpkgs/stable/#chap-quick-start

One thing is that in src it often uses sha256 = instead of hash = which is used in the Fetching Sources section. The manual should provide consistent information.

• [ ] https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/he/hello/package.nix
• [ ] https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/archivers/cpio/default.nix
• [ ] https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/gmp/5.1.x.nix
• [ ] https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/newsreaders/pan/default.nix
• [ ] https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/http/apache-httpd/2.4.nix
• [ ] https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/browsers/firefox/common.nix
• [ ] https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/misc/jdiskreport/default.nix
• [ ] https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix
• [ ] https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/adobe-reader/default.nix

[mibmo]

Most of them are using rec instead of the finalAttrs pattern (I'm not sure what it's formally called), see https://github.com/NixOS/nixpkgs/blob/3c15feef7770eb5500a4b8792623e2d6f598c9c1/pkgs/tools/archivers/cpio/default.nix#L12 https://github.com/NixOS/nixpkgs/blob/3c15feef7770eb5500a4b8792623e2d6f598c9c1/pkgs/applications/misc/hello/default.nix#L10

Seems that they aren't run through a formatter either.

I'm by no means an expert, but the first one looks good to me (except the sha256 instead of hash). :)

[mjarosie]

Additionally, GNU Hello package was deleted or moved, so the first link shows 404 error.

[rjpcasalino]

@mjarosie the unstable nixpkgs manual has moved the docs to a new location the hello example is here now pkgs/by-name/he/hello/package.nix - I assume the unstable nixpkgs manual rolls out later this month

[doronbehar]

I read today this part of our docs:

https://nixos.org/manual/nixpkgs/unstable/#mkderivation-recursive-attributes

And it is not stated firmly whether using a function as an mkDerivation argument is better then the old rec {} option. I was wondering if that's intentional, and whether there are reasons not to use a function as an mkDerivation argument. I was pretty sure until I read this part that there is a strong consensus in favor of using finalAttrs: instead of rec {}... cc @roberth as the main pusher of the finalAttrs: pattern.

[nbraud]

I was pretty sure until I read this part that there is a strong consensus in favor of using mkDerivation...

Don't both use mkDerivation? Could you clarify, @doronbehar ?

[doronbehar]

I was pretty sure until I read this part that there is a strong consensus in favor of using mkDerivation...

Don't both use mkDerivation? Could you clarify, @doronbehar ?

You are right, I wasn't clear, that "mkderivation..." should have been "finalAttrs:..." I edited that comment...

[nbraud]

Most of them are using rec instead of the finalAttrs pattern (I'm not sure what it's formally called), see

For what it's worth, I think part of the problem is that many builders still do not support explicitly-recursive attrsets.

234651 introduces helpers which would make it much easier to support the pattern in all builders, FWIW

[mibmo]

Most of them are using rec instead of the finalAttrs pattern (I'm not sure what it's formally called), see

For what it's worth, I think part of the problem is that many builders still do not support explicitly-recursive attrsets.

234651 introduces helpers which would make it much easier to support the pattern in all builders, FWIW

It's worth considering the eval time impact to nixpkgs as a whole too. I don't quite remember where, but I vaguely recall reading that a not-insignificant portion of the eval time is from derivations utilizing the finalAttrs pattern.