The killer feature would be pulling in other scripts as libraries (they may be published anywhere) but I can lock down the hash of these dependencies inside of my script file.
Is this possible?
The killer feature would be pulling in other scripts as libraries (they may be published anywhere) but I can lock down the hash of these dependencies inside of my script file.
Is this possible?
There's a few reasons why this might be annoying to deal with in practice, so we're working on a few different ways of managing versions throughout your script
There's a great list here
https://dbohdan.com/scripts-with-dependencies
but be aware that a lot of those are through third party tools and therefore don't have proper IDE support etc.
* you said locking the hash in the script, and in the nix approach these are generally locked in either a lockfile or in the nix expression.
Can elaborate if you're curious.
I would love for the Nix lock to somehow be embedded in the script.
At the risk of overstepping (it sounds like you might be a little interested) here are a few links in to some basics just-in-case.
For context, I extracted my bashrc into its own repo, and it in turn sources bash libraries for my shell history and git status plugins. It's also leaning on some libraries that are pulled in through those two. (To be clear, this is just a general example of the flake pattern with a separate lockfile. I can find or synthesize something with the inline script pattern if you ask.)
- Source statements: https://github.com/abathur/bashrc.nix/blob/e7c437578e2a623f4...
- Nix expression responsible for resolving and ~linking these two dependencies in to the final script: https://github.com/abathur/bashrc.nix/blob/e7c437578e2a623f4...
- Flake inputs for the two dependencies. Note that these can be specified as just the repo or a branch and updated by updating the lock through Nix, or they can be ~pinned to a specific rev: https://github.com/abathur/bashrc.nix/blob/e7c437578e2a623f4...
- A gist with examples of the entire chain of scripts that get resolved together here: https://gist.github.com/abathur/09f06f1f34b003376017d7a5c031...
These all get handled separately, so they can technically have divergent implementations of the same external command (for example, one library could depend on libressl and one could depend on openssl--and each resolved library would independently point to the correct one.