Using services.telegraf.package to pick most up-to-date version?

Good morning everyone!

I have been running into an issue with gosmi and the MIB parsing in Telegraf and was thus told to update to 1.29 - but, NixOS 23.11 only has 1.28.x so I would like to bypass that.

I used this reply here Installing only a single package from `unstable` - #4 by fricklerhandwerk and added nixpkgs-unstable as an additional part in my config. However, my brain somehow missed the memo that this repo, even as a tarball, is quite large.

So I would like to know how I can get just this package, Telegraf, to use 1.29.x instead of 1.28.x from the stable 23.11 nixpkgs? I mean I could use the Github Raw URL and a fetcher, but I have no idea if that would even actually work - as far as I understand, just ripping out the package definition (pkgs/servers/monitoring/telegraf/default.nix) won’t be sufficient.

Thanks, and kind regards!

Thanks a lot!

Only using the package definition file in isolation, if it’s really just that file, and evaluating it with callPackage, is in principle possible, but may not work: you’ll get the dependencies from your current Nixpkgs, and those may not be the right version. But it’s worth trying!

The new package will have to be compiled locally, which is particularly annoying because that will almost certainly happen on every update of your Nixpkgs source.

This can be smoothed out a bit by setting up remote build machines and a cache, but only if you have the motivation to get into it. AFAIK there is no straightforward documentation for how to do all that quickly, because the tooling to make that really convenient even on your own hardware appeared only recently.

If there are failures, you may have to do the same thing for a bunch of dependencies though, and wire it all up. At that point having a second copy of Nixpkgs and the corresponding closure is obviously more reasonable. This overhead is a small price to pay for the incredible convenience and robustness you get in return.

Just make sure to pin both versions, so it doesn’t inadvertently update on every evaluation — unless that’s what you want, which is meaningful if you want particular packages to always have the most recent available version, in which case you’d keep nixpkgs-unstable unpinned.