Fork me on GitHub
onetom03:07:10 mentions that I can use aliases to assemble a value from aliases for the value for :paths. is that possible to do something like this for :extra-deps and similar hash-maps, within aliases?


my motivation for doing this is to reduce some repetition in dependency definitions.


Not at the moment. Only :paths can accept keywords and treat them as aliases I believe. Some tools support this, such as depstar and deps-deploy, for some of their exec args. I'd like to see this be more widespread.

👍 6

thank you! i will have a look how you did it.


Is it possible to mix, say a function execution that does something, i.e., -X:foo with a set of aliases -M:bar:baz, i.e., clj -X:foo -M:bar:baz


so that foo would run first, then aliases next? Or perhaps I'm going about this the wrong way?

Alex Miller (Clojure team)14:07:00

If I’m guessing what you want, no

Alex Miller (Clojure team)14:07:16

Each clj call runs a single program

Alex Miller (Clojure team)14:07:20

One new capability in latest release is that you can chain multiple functions together, but they run serially which I suspect is not what you want


A bit of background, I'm porting a lein project.clj to deps. Part of our system uses a local docker stack, with random external ports. There's in-house lein plugin that introspects the docker stack running and spits out the ports for injection into the environment for development. I've ported that plugin to a little program that I can invoke using clj -X:foo. It's tedious to write out the ports each time (as the stack can bepulled up and down several times a day). So I wasn hoping to have something that ran a function (this one) then fired off the aliases that would then start up my repl etc...

Alex Miller (Clojure team)14:07:43

You can use whatever you like to make two calls around clj, or you could write a program that did two things and call that

Alex Miller (Clojure team)14:07:27

Chaining might work well for this


serial execution is fine, but I wonder would it work with the repl programs, such as rebel-readline that uses a main method to start up


so, it's like I want to run a function before then handing off to the -M aliases, perhaps that function, like in this case, is a pre-start bit of work


@dharrigan Is there a need for the first script to run inside the Clojure JVM environment?


no (in fact, all it does is shell out to docker to get a list of runnig services, then use a bit of clojure code to write them out neatly into edn format)

Alex Miller (Clojure team)14:07:49

this won't work with clojure.main programs so you'd need a wrapper -X style entry point to get to the repl (which would maybe be something we could provide)



Alex Miller (Clojure team)14:07:44

the actual repl entry point function inside clojure.main is actually a vararg method so it would actually work as an entry point automatically IF you are using Clojure 1.11.0 alphas with trailing map support for kvarg functions

Alex Miller (Clojure team)14:07:09

but you'd probably want a set of default supplied anyways, needing a wrapper


good point. I'll have a ponder over the weekend (I mean, I could always just do clj -X:foo && clj -M...... 🙂


but maybe babashka, with it's tasks may help out as well 🙂

Alex Miller (Clojure team)14:07:29

yeah, there are many ways to skin this cat (which is why I don't see a need to add another one :)


so tools.deps.alpha is for dynamically adding a library without restarting the repl right? How are folks using this universally in all their projects? I'm assuming putting it somewhere in their /clojure/deps.edn config? I'm thinking of putting it in my repl alias as I'm always using that to start a cider nrepl anyways

Alex Miller (Clojure team)19:07:14

no, that feature is not available in the mainline code (it is available on an experimental branch and may be merged in some form at a future time)


no worries, thanks


@chase-lambert I use that experimental branch all the time. My dot-clojure repo has that and a bunch of other aliases in it: see the usage notes here


I did a REPL-Driven Development talk about six months ago -- for both the London Clojurians and Provo Clojure -- and in that talk/demo I show how to use it with deps.edn to load new dependencies into the REPL while I'm working.


Does this mean if I add that in to my deps.edn I could do something like clj -M:add-libs:repl to run both aliases? I am still confused on how to call multiple aliases because I thought I read only the "last" alias allows for :main-opts or something


I'll rewatch that talk, I think that is where I originally saw this possibility


With :main-opts only the last one wins, so it depends what is in your :repl alias?


But, yeah, in this case :add-libs only loads extra (git) deps, so it would combine with your :repl alias too.


the repl main opts are basically nrepl middleware and "-i" to get a prompt


it looks like your :add-libs alias needs some Dynamic Class Loader options going on or something though


That's really for Socket REPLs which don't currently have a DCL. Pretty sure your nREPL setup will have a DCL.


sounds good, I'll give this a shot, thank you


Feel free to DM me with Qs if you have problems. There aren't many of using add-libs...


thanks! It seems to be working great in the repl. I was thinking it would add the dependency to my project's deps.edn for me though.


Nope, just in-memory. Which is why, in my demo, I do that weird dance with #_ and code actually in my deps.edn file 🙂


So I edit deps.edn to add the dep, then run add-libs on it in-situ to actually load the new dep into the running REPL.


Awesome, I'll go check it out again soon. My lazy self also wants to find a way to auto load the (require '[ ...) at repl start too but I'll leave you fine folks alone on that (for now) haha


Put it in user.clj


Clojure loads that when it starts up.


I was thinking that's how it is done. So it just runs all the code found in that file automatically? It has to be on a certain path?


Yeah, so it's usually best to have a :dev alias that adds the path containing user.clj so it doesn't get into your production code. It just needs to be on the classpath.


(so you might have dev/user.clj and then :dev {:extra-paths ["dev"]})


yep, just saw that here: which is based on your own example repo. Thanks again


I feel like the more I learn these tools.deps the more I'm going to keep wanting to run multiple aliases depending on what I'm doing but then this only one alias's main opts thing will be tripping me up constantly. That's not accurate though?


These days I run most stuff via -X, even if that means writing a little wrapper around someone else's actual -main function 🙂


:exec-args composes across multiple -X aliases.


yeah it's time to sit down and really grok this official deps and cli reference docs I think


If you have the :new alias (from clj-new) and run clojure -X:new :template app :name chase/example you'll get a small, simple project that uses -X for most stuff.


(and soon these tools will be even easier to install and use -- see Alex's clojureD talk that was just released to YouTube today)


Ironically I decided not to use clj-new this time to force myself to learn these things myself. haha. Yeah I have all those clojureD talks lined up to watch, they all look interesting.


It was a great conference! I attended "live" and the virtual environment was really good.


Kind of brutal, time-wise, since I'm in California 🙂


At work, we're preparing for -- and we've been using deps.edn since 2018. Just recently we replaced our ad hoc bash-based build scripts with a short build.clj program (which my colleague is refactoring today), and we use -X invocation for a lot of tasks already.


I've been updating depstar so it has multiple "tasks" that can be run individually via -X or together, but I'm waiting for to become available so I can finish that work off in a way that is compatible (with so you should be able to swap out some of the built-in tasks for depstars version of them (sync pom.xml, compile Clojure, build a JAR or uberjar).