This list looks great. Any thoughts about plugins for plum?
I realise plugins are a slippery slope, but if done properly they do have the benefit of allowing some development to happen semi-independently of the core plum code base.
What would plug-ins do, exactly?
What would plug-ins do, exactly?
Anything that isn’t in the command list above (and arguably that list ultimately as well). If commands were pluggable, it would allow the community to extend plum in ways you may not have envisaged or have time / interest to develop yourself, without having to work on the core codebase to make them available to users of the tool.
tl;dr - the main benefit is to decentralise and democratise development of new commands.
Well, atm plum executes clojure -A:plum/$@ so you can certainly add your own “plum commands” to any deps.edn:
:aliases {:plum/foo ...}
And execute via plum foo.
I’m not sure how much ceremony I want to add to that right now, since I want to ensure that we can support the canonical set of commands at least.
I think it would be easier and simpler to direct users that want to provide similar commands that might extend beyond plum’s defaults to use clojure directly, e.g.:
:aliases {:foo ...}
Executed by clojure -A:foo.
This is a super interesting proposal! I think it addresses a bunch of pain points with the current CLI tools, covering problems that have previously only been adequately solved by Boot and Leiningen.
This is a maybe getting ahead of things a bit but one thing I’d think might be interesting to consider in the context of upgrade-ability is something that Boot does really well. For every Boot task there is a symmetry between CLI invocations and Clojure forms:
boot push --pom pom.xml --file some.jar --gpg-sign
(push :pom "pom.xml"
:file "some.jar"
:gpg-sign true)
This example is slightly contrived but this upgradeability (into real code) is super nice when you want to eventually combine multiple steps into one. As soon as you outgrow the “run individual commands in sequence” approach I think this is a great affordance. This becomes particularly apparent when you want to combine multiple long-running commands at the same time, like running tests and cljs compilation on filesystem changes.
I think kaocha implements a similar system but @plexus will be more knowledgeable about that.
I don’t think this should be anywhere near the top in terms of priorities but maybe it is something that could be considered for generally being in scope of plum.
Keep it up, excited to see this become a thing! The reference to create-react-app (from the little I know about it) really makes sense and having some comparable tooling in the Clojure ecosystem would be awesome for anyone getting started with Clojure!
1 Like
I would really love to have this! I was hoping for something like pip, npm, go get, or cargo, which you could use to install an executable project (it pulls the dependencies and puts an executable in your PATH).
I’m kinda new to the JVM ecosystem, and surprised to find out that to use an app built in Clojure, I have to somehow get the uberjar (build from src or download with maven), and manually create a shellscript for it and put to PATH.
1 Like
Hi all!
I am reading and reading this and can’t help but thinking that while it would for sure solve some issue with the current tools.deps setup, it would be awesome if this idea would percolate back into clojure itself 
In any case good job there!
And a way to share common aliases to “trusted” libs (like clj-new), nice! I like it! And my local deps.edn will definitely become smaller.
1 Like
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. 
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.
5 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? 
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
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.