Oh wow! I never would have guessed this was a behavior of the `rec` keyword! Nice idea! I'll play around with it to verify my understanding and then submit a PR to the NixPkgs manual to note this behavior for other people who might discover this pitfall. That'll take me several days. :)
Much appreciated, Layus! On Thu, Jun 30, 2016 at 12:01 PM, Layus <[email protected]> wrote: > On 30/06/16 20:18, Alex Berg wrote: > > I created a new "~/.nixpkgs/config.nix" file to customize the > nix-channel-obtained nixpkgs copy on my system - my goal was to bump the > version of Vim to a specific version. > > My first attempt was to override the derivation and simply set the > "version" attribute, like this: > > { > packageOverrides = pkgs: rec { > vim = pkgs.vim.overrideDerivation (oldAttrs: { > version = "7.4.1941"; > }); > }; > } > > But this had zero effect on the name of Vim I saw when using "nix-env > -qaP" to see package details. The Vim package's definition has the "name" > attribute defined like this: > > name = "vim-${version}"; > version = "7.4.1585"; > > so I expected my overriding the "version" attribute to affect the > package's name, but it did not. > > No, because the definition above relies on the "rec" keyword, but "rec" > has already been applied *before* overrideDerivation. > Overriding "version" will not override "name", and in turn will not > override "src". > In fact, overriding "version" will have no impact on the output path as > that parameter is not used by mkDerivation. > But the attribute is overriden. ` nix-instantiate "<nixpkgs>" --eval -A > vim.version ` will give you the new version string. > > Overriding "name", for example, will have impact as it is used by > mkDerivation to compute the output path. > Again, it is not sufficient to build a different version of vim. See below. > > > After asking the #nixos IRC channel, one person suggested the "version" > attribute isn't overridable because it isn't an attribute the *primitive > derivation* set. Based on this guess, I changed my ~/.nixpkgs/config.nix > definition from that to this: > > let > vim-version = "7.4.1941"; > in > { > packageOverrides = pkgs: rec { > vim = pkgs.vim.overrideDerivation (oldAttrs: { > name = "vim-${vim-version}"; > src = pkgs.fetchFromGitHub { > owner = "vim"; > repo = "vim"; > rev = "v${vim-version}"; > sha256 = "0apq7sv1fbyfzqh4q0r2z19bn4gbjlb97wyl80kj7qsqmsy7m1lm"; > }; > }); > }; > } > > My guess is this works because I'm overriding the "name" attribute. > > No, it works because you override the "src" attribute. > src is used by mkDerivation, so overriding modifies the package to be > built with the new source tree. > Overriding the name is not strictly necessary, but is a *very* good > practice, as otherwise you would get a 7.4.1941 vim with the old version in > the name... confusing :-) > > > I read the definition of the "mkDerivation" function > (pkgs/stdenv/generic/default.nix), > but it doesn't have a simple list of attributes that are overridable, but > is rather flexible. Also, that definition doesn't mention a "src" > attribute, but "src" attribute is overridable, so I wonder why overriding > the "src" attribute works. > > Where can I find explanation for this? If there is a restriction on which > attributes are overridable, then I'd like to note this in the NixPkgs > manual, here: > <https://nixos.org/nixpkgs/manual/index.html#sec-pkg-overrideDerivation> > https://nixos.org/nixpkgs/manual/index.html#sec-pkg-overrideDerivation > > Everything is overridable separately, but you cannot count on the rec > keyword at override time. > Every attribute already has a fully defined value. > > > > > _______________________________________________ > nix-dev mailing > [email protected]http://lists.science.uu.nl/mailman/listinfo/nix-dev > > > > _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev > >
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
