We already have our source in version-control.... we just need a way of updating and maintaining a repository with external dependencies.
Do any such tools exist?
Nix 'packages' are just text files describing the build/install process, so they can be version controlled (e.g. there's a big repo at https://github.com/nixos/nixpkgs ).
Dependencies, build environments, etc. are fully specified by the package and isolated from each other, and there is an emphasis on reproducibility, so building/installing a particular package should always give the same results. (This isn't enforced, but a non-reproducible package is considered buggy, and there are tools to check if a package can be reproduced)
Nix packages themselves can reference external dependencies, like git repos and URLs, and usually provide a fixed checksum to compare the output against; if it doesn't match, the build is aborted. Wrappers/translators are also available to integrate with other package manager ecosystems, e.g. cabal/hackage for Haskell packages.
Results are cached locally (packages are only built once, until they get garbage collected) and remotely (if a build server has already built a package, you can fetch it from there instead).
For development environments, you can write a Nix package for your project then run the 'nix-shell' command to enter its build environment (i.e. all dependencies available, environment variables set, etc.)
Isn't this effectively equivalent to version-controlling a shell script that contains a set of 'curls' or 'clones'?
What I had in mind would be more invisible and self-contained within the VCS.
It would effectively be a meta-VCS.
I would not do that. I would fork the repositories I wanted and tag them along with your version. (mulle-bootstrap tag comes to mind :))
The embedding could be done with .bootstrap/embedded_repositories, which may or may not fit the bill.
I can download any docker image. Docker image contains all external dependencies and I can inspect those dependencies.
I assign a version to each Dockerfile. Docker image version is in the source control. Image with each version is stored in docker image registry. Version bump triggers update of all packages (either system level or language packages). This lets me revert external dependencies to state from any point in time. Or check out any commit from source control and run it in the same state as it was running in prod at that time.
My point is that this function should effectively be part of the VCS.
[1]: https://git-scm.com/book/en/v2/Git-Tools-Submodules
[2]: https://developer.atlassian.com/blog/2015/05/the-power-of-gi...
What I'm thinking of is a link to a version of an external repository.
(It may be working like that, but I've never used it like that if so).
Actually, yes... what I would like is an explicitly versioned "submodule" or "subtree" command where I can manage the exact versions within the VCS.
Subtree works a little bit different. It is essentially a copy of an external repository instead of a link.
Ultimately its basically a set of external dependencies that you want to version-control and occasionally update.
I see no fundamental difference to what version-control is, its just not a feature built into most/any.
One such tool:
That seems basically like you create a specification for what versions of which repos you want and it will create it.
Is that any different to just having a shell-script curl the repos and versioning that script?
What I had in mind would be effectively external dependencies that would appear within the source tree when cloned/manifested/whatever which would themselves be version-controlled. It would effectively be a 'curl' or 'clone' of an external version of a child repo maintained by the VCS.
Does that make sense?