[Idea] A tool for helping developers get started using Clojure CLI tools and deps.edn

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.

FWIW, this was very close to the original vision I had for depot https://github.com/Olical/depot

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.

2 Likes

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.

4 Likes

I’ve updated plum add to support git deps and local roots as well. :tada:

I think the next hard thing to tackle will be figuring out a packaging/building command: I know there are a few aliases out there for doing this.

I’ve created an issue over at https://github.com/Lokeh/plum/issues/4. Please provide recommendations and comments!

1 Like

I’ve also started a site explaining what plum does and how to install it: https://laughing-banach-af1115.netlify.com/

1 Like

+1 to this as a general principle.

4 Likes

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? :slight_smile:

3 Likes

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.

1 Like

Cross-posting here since the #plum channel still only has 4 people (you should all go join!)
I’d appreciate feedback on this: https://clojurians.slack.com/archives/CJFRQS61Z/p1559176465011800

Ah I see, I know nothing about the pain needed to deal with native-image, so it was a suggestion made in blissful ignorance. :^)

1 Like