I’ve just tagged v1.0 of Repoint, a tool for managing library source code in a development project. Conceptually it sits somewhere between Mercurial/Git submodules and a package manager like npm. It is intended for use with languages or environments that don’t have a favoured package manager, or in situations where the dependent libraries themselves aren’t aware that they are being package-managed. Essentially, situations where you want, or need, to be a bit hands-off from any actual package manager. I use it for projects in C++ and SML among other things.
Like npm, Bundler, Composer etc., Repoint refers to a project spec file that you provide that lists the libraries you want to bring in to your project directory (and which are brought in to the project directory, not installed to a central location). Like them, it creates a lock file to record the versions that were actually installed, which you can commit for repeatable builds. But unlike npm et al, all Repoint actually does is clone from the libraries’ upstream repository URLs into a subdirectory of the project directory, just as happens with submodules, and then report accurately on their status compared with their upstream repositories later
The expected deployment of Repoint consists of copying the Repoint files into the project directory, committing them along with everything else, and running Repoint from there, in the manner of a configure script — so that developers generally don’t have to install it either. It’s portable and it works the same on Linux, macOS, or Windows. Things are not always quite that simple, but most of the time they’re close.
At its simplest, Repoint just checks stuff out from Git or whatever for you, which doesn’t look very exciting. An example on Windows:
Simple though Repoint’s basic usage is, it can run things pretty rigorously across its three supported version-control systems (git, hg, svn), it gets a lot of annoying corner cases right, and it is solid, reliable, and well-tested across platforms. The README has more documentation, including of some more advanced features.
Is this of any use to me?
Repoint might be relevant to your project if all of the following apply:
- You are developing with a programming language or environment that has no obvious single answer to the “what package manager should I use?” question; and
- Your code project depends on one or more external libraries that are published in source form through public version-control URLs; and
- You can’t assume that a person compiling your code has those libraries installed already; and
- You don’t want to copy the libraries into your own version-control repo to form a Giant Monorepo; and
- Most of your dependent libraries do not similarly depend on other libraries (Repoint doesn’t support recursive dependencies at all).
Beyond mere relevance, Repoint might be actively useful to your project if any of the following also apply:
- The libraries you’re using are published through a mixture of version-control systems, e.g. some use Git but others Mercurial or Subversion; or
- The libraries you’re using and, possibly, your own project might change from one version-control system to another at some point in the future.
See the README for more caveats and general documentation.
The biggest current example of a project using Repoint is Sonic Visualiser. If you check out its code from Github or from the SoundSoftware code site and run its configure script, it will call out to
repoint install to get the necessary dependencies. (On platforms that don’t use the configure script, you have to run Repoint yourself.)
Note that if you download a Sonic Visualiser source code tarball, there is no reference to Repoint in it and the Repoint script is never run — Repoint is very much an active-developer tool, and it includes an
archive function that bundles up all the dependent libraries into a tarball so that people building or deploying the end result aren’t burdened with any additional utilities to use.
I also use Repoint in various smaller projects. If you’re browsing around looking at them, note that it wasn’t originally called Repoint — its working title in earlier versions was
vext and I haven’t quite finished switching the repos over. Those earlier versions work fine of course, they just use different words.