Shell.nix: attempt to do inline package override not working

In a nix dev shell I’m trying to directly override a package version, in the hope that it will simply build the needed derivation using a new ${version} value:

{ pkgs ? import <nixpkgs> {} }:

  stdLibPath = pkgs.lib.makeLibraryPath [ ];
pkgs.mkShell {
  buildInputs = with pkgs; [
    clang go_1_17 cmake which git git-lfs ping
    gtk3 libdatrie libxml2 zlib-ng
    libselinux libsepol
    libthai libxkbcommon xorg.libXdmcp xorg.libXtst
    ninja pcre pkg-config wget appimagekit appimage-run
  ] ++ (with import (builtins.fetchTarball
      "") { config = { allowUnfree = true;}; }; [
    (flutter.overrideAttrs ( oldAttr: rec { version = "3.0.0"; }))
  shellHook = ''
    export LD_LIBRARY_PATH=${pkgs.libepoxy}/lib:${stdLibPath}
    export SSH_AUTH_SOCK=/run/user/$UID/keyring/ssh
    export GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt
    export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt

In this case, flutter unstable is at 2.10.x and the derivation has version in it’s argument list, which appears to be used (as per convention) to determine which version needs to be built. I’m trying to simply build 3.0.0 by overriding version, anticipating it would behave the same as in an overlay (and if the derivation would need more tweaks I’d add them step by step).

It appears however, that the override is simply ignored and I get a shell with the default flutter version.

The version attr usually drives the src, and the src attr isn’t automagically updated by overriding the version.

It appears that for flutter the case is much more complex, and in fact version is an argument.
Would that mean that I should somehow use callPackage inline with arguments, referring to the .../flutter/default.nix file belonging to e.g. pkgs in the nix-store?
(I tried some if it, but got all kind of syntax errors)

As for the (in this context not applicalble/academical) case with “normal” version and source: if e.g. the drv reads something like

... mkDerivation {
   pname = "someprog";
   version = "0.1.1";
   src = {
       name = "...${pname}...";
       url = "....${version}...";

why would version then not be used if it is overridden?

That derivation isn’t what you think it is. By looking in all-packages.nix

flutterPackages =
  recurseIntoAttrs (callPackage ../development/compilers/flutter { });
flutter = flutterPackages.stable;

—you can learn that flutter is actually flutterPackages.stable, and the file you’re reading is flutterPackages.mkFlutter. So to build a different version of Flutter, you’d need to imitate how stable is built, passing different parameters into mkFlutter.

1 Like

Additionally, you might find Flutter: 2.10.1->3.0.0 to be a useful reference, but it’s currently a draft with some unresolved problems.

1 Like

Ah, yes, I’m afraid it’s too non-standard to just override…

As for the upcoming update, good catch, I suppose the energy would be better spent to wait/contribute to that one indeed. (I was just kinda in a hurry to review a flutter app a colleague made in 3.0.0, but I can build it in a container and run with steam-run which works ok too…)