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.
I never went through with it and just stopped at the outdated checking (hence the specific namespace name to make room for others). This sort of tool could be really powerful in the community, especially since it’s entirely optional and is built on top of common tools.
The main thing I did with Kaocha is designing an API namespace, and having the CLI be a thin layer over that. This is something I can highly recommend, think from the start about how people might call your tool programmatically, and consume that API layer yourself.
This is all very promising, and I think there are a ton of great ideas here! I would just caution you to be careful about where you draw the line in terms of packaging boundaries for a while because that is a vast task itself. For example, this talk about GUI and daemon apps opens many huge cans of worms, such as application-native icons, dock integration, code signing and installer building on the Mac… it would take a big team a long time to get right, and it would probably be better to just wait for the OpenJDK project to finish the jpackage tool and leverage that to turn your überjar into a well-behaved native application launcher or installer: https://bugs.openjdk.java.net/browse/JDK-8200758
Haven’t read the whole thread, but since no one has mentioned graal/native-image; maybe you could have a plum build bin which uses graal to build a native image?
This has been in the back of my mind because the time it takes currently to do things like e.g. plum add clj-time "0.15.0" is far too long for my tastes. However, I expect I would have to spend a lot of time to get individual commands native-image compatible.
