Hum… that aka thing seems a lot like what I was thinking. The pack.edn doesn’t seem to be documented, and where to host it as well.
But my thoughts were that you’d have a new edn format, like say package.edn. And that you could do something like:
plum install bla/foo/package.edn
And based on that package.edn file, the correct alias would be added, and shell launcher created and added to your path for it. And then you could do a
plum update and it would update all your packages.
Maybe there could even be a hosted repo of package.edn files. Or maybe github could be the repo, so you’d just have to host the package.edn file on github either by itself or at the root of the actual project repo and then you could do
plum install foo/bar
Where foo/bar is a github repo. And it would look for that package.edn file in it. Having a custom hosted repo would allow listing and searching for packages which could be nice though.
Now the trick would be for what data goes into package.edn. You probably want some metadata along with the alias. And off course, creating the CLI for it. As well as handling the installation, it could get tricky, like what if there are name clashes on the path, how to support windows, what about installing GUI or daemon apps? Etc.
But the potential is there.