I see what you are saying here ok. There are more factors than just using an overlay to override attributes in nix.
@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?
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.
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).
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