How to install a previous version of a specific package with configuration.nix?

[samrose]

@rgoulter

Abstractly, substituting version B for version A relies on the two interfaces being close enough.

Upthread, an example is given where the recent NixOS module code assumes the Nix derivation (Nix package) it’s given has certain attributes. When the older Nix derivation is given, the NixOS module doesn’t build because the assumption breaks.

Maybe using the older NixOS module alongside the older package would work (or maybe there are further incompatibilities between that module and other modules). – Another way of working around “incompatibility between new module old package”: copy-paste the NixOS module & beat it into working shape.

I see what you are saying here ok. There are more factors than just using an overlay to override attributes in nix.

[drmikecrowe]

@rgoulter

age.nix { inherit (specificPkgs) bun; };. (Or perhaps even overriding the bun passed to an existing package).

@rgoulter – I don’t disagree, but in my case I was trying to get SST working. It requires specific versions of bun and pulumi, so I felt locking them down in the package was the right way to do this. Does that make it OK?

[rgoulter]

@drmikecrowe

I was trying to get SST working. It requires specific versions of bun and pulumi, so I felt locking them down in the package was the right way to do this.

I think “it’s not really variable” is a good argument for why you might arrange it like that.

My intuition against it is it’s nicer for “what I know about SST” to be in sst.nix, and “what I know about bun” to be in bun.nix. If the package recipe’s attributes had docstrings, I’d certainly put “must be this specific bun version” for the bun. (Or perhaps mimick how nodejs_20 suggests a specific version).

An advantage to having bun as a parameter is it’d let you try the package with different versions of bun. (e.g. built with more features, or built with fewer features, or etc.). Whereas if the dependency isn’t exposed as an attribute to the package recipe, you’d have to modify the source code to vary that.

@drmikecrowe

Does that make it OK?

I think this is ‘OK’ in the sense that it works.

I’d argue that fetching a particular version of nixpkgs within a package recipe isn’t a very tidy/elegant thing to do. (In kinda the same sense that it’s nicer to have a package definition that builds from source compared to one that runs a prebuilt binary).

[drmikecrowe]

@rgoulter

I’d argue that fetching a particular version of nixpkgs within a package recipe isn’t a very tidy/elegant thing to do. (In kinda the same sense that it’s nicer to have a package definition that builds from source compared to one that runs a prebuilt binary).

Agreed – my solution is a hack, but sometimes you just need a hack to test something out LOL. The right solution is to build from source as you recomment