https://clojure.org/reference/deps_and_cli#_paths 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?
thank you! i will have a look how you did it.
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.
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?
If Iām guessing what you want, no
Each clj call runs a single program
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...
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
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)
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)
Interesting!
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
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 š
thank you @alexmiller and @borkdude!
yeah, there are many ways to skin this cat (which is why I don't see a need to add another one :)
meow!
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
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 https://github.com/seancorfield/dot-clojure/blob/develop/deps.edn#L202-L224
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 '[clojure.tools.deps.alpha ...)
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: https://github.com/prestancedesign/usermanager-reitit-example 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 tools.build
-- 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 tools.build
to become available so I can finish that work off in a way that is compatible (with tools.build
) so you should be able to swap out some of the built-in tasks for depstar
s version of them (sync pom.xml
, compile Clojure, build a JAR or uberjar).