Clojurians Log v2

I'm curious how RELEASE resolves in this maven dep...

{:extra-deps {clj-kondo {:mvn/version "RELEASE"}}
   :main-opts  ["-m" "clj-kondo.main"]}

RELEASE (and LATEST) are special "virtual" version numbers that tell Maven to look for the newest released version (non snapshot)

they are officially unsupported by clj (but do kind of work with some big caveats)

big caveat #1 - they break caching and you will never see a new release after the one that it first resolves to unless you -Sforce (or otherwise cause a cache recompute)

at some point, we may actually prevent caching at all if you use these "versions"

subtle caveat #2 - the answer you get is only as good as the metadata index in the repository. for maven or clojars, no worries. if you're using a bespoke s3 repo, then you probably aren't updating the right metadata files and you usually won't see the newest version

generally, I think it's harmless to do this in -Sdeps to grab "latest". it's mildly bad to do it for tools in your deps.edn aliases (like the example here). it's very bad to do it for your project deps.

Does there happen to be an equivalent for git/sha coordinates? That could be quite handy…

@pmonks My dot-clojure deps.edn shows how you can resolve the head of the default branch -- in the comments.

https://github.com/seancorfield/dot-clojure/blob/develop/deps.edn#L171-L175

And then (load-master 'clojure/tools.trace)

(following the http://github.com URL pattern, not the org.clojure/tools.trace Maven artifact pattern)

Potentially dumb question, but is it expected that code inside an EDN file would be executed? Or does that rely on a coincidence of how the Clojure EDN reader functions?

@pmonks Can you give a specific example?

I mean, EDN can contain tagged literals and you can provide reader functions that process those... but that's not exactly "code inside an EDN file".

edn files are data, not code, and are not evaluated

They are read but that will only construct tagged literals, and clj does not provide a way to install readers for tagged literals

Intentionally not, for the same reasons re caching

@seancorfield your example includes code (`(require '[clojure.tools.gitlib :as gitlabs]) …`) - how is that code evaluated?

I guess I don’t understand the caching issue. If you resolve “RELEASE” to a concrete version, and that version happens to exist in the cache already, wouldn’t tools.deps use it?

(and conversely, if it doesn’t, wouldn’t that version be added to the cache, and thereby eligible for future “cache hits”)

The caching is based on time stamps of deps,edn files. If the file never changes (set to RELEASE), the class path is never recomputed, even if newer versions come out

Those are comments showing what you would execute in your REPL...

Caching of classpath (not lib version)

The files contains lots of comments explaining how to use the aliases, with links to repos.

Ah ok. I assume there’s a good reason for making the deps.edn file the cache key, rather than just recomputing dependencies the classpath every time and having those in the cache?

Recomputing deps starts a second JVM so it’s at least a second, usually more depending on io

Oh ok. So I would not put those in a deps.edn then.

Huh? Those are comments and they are in a deps.edn file.

This is why clj starts faster than lein usually

It also goes to build repeatability

Yes they are, and as a result I would expect to uncomment them and have them Just Work:tm: .

I mean, that repo literally is my ~/.clojure/deps.edn file.

But if I’m following you, you’re saying that’s not correct - that those lines need to be copypasta’ed into a REPL.

Forgive me but I'm a bit shocked you would think code in EDN files would be evaluated...

I didn’t - that’s why I asked the question.

Or “clj repeatability”

I was quite surprised to see commented out code in an EDN file.

(and by “quite”, I mean “very”…)

Regardless, @alexmiller separately explained that by design you can’t do an equivalent of RELEASE for git/sha coords in a deps.edn file.

https://github.com/practicalli/clojure-deps-edn/blob/master/deps.edn contains comments with lots of shell commands, and even some elisp -- you wouldn't expect any of that to be executed just by reading the EDN file, would you?

Why would you assume I’ve read some random deps.edn file? Sadly I don’t have that much disposable time…

Well, you read my file and came to a ... strange conclusion ... so I offered another example deps.edn and wondered what conclusion you would come to from that...

Ok. I’ll assume there’s a good reason for needing a second JVM to do that (not requesting an explanation, btw, unless you’d like to provide one), and understood full well the performance implications of starting a JVM.

If you re-read my original question (https://clojurians.slack.com/archives/C6QH853H8/p1595913713054800), you might see why I was assuming a deps.edn-only solution, and therefore didn’t understand your non-`deps.edn` answer.

In general, answering questions people didn’t ask is a wonderful source of confusion. 😉

With the Clojure CLI/`deps.edn` the "equivalent" to Maven/Leiningen/etc is often "some code that you run" -- which seemed like an acceptable answer to your question.

That's why I was so puzzled by your follow-up question, as it seemed unrelated to my answer (I was thinking "No, of course reading EDN won't execute code!").

I guess I should add "Here's some code you can run in your REPL" to my deps.edn file where there are code examples 🙂

That would have avoided any confusion, no doubt. 😉

It is sometimes so hard to predict your audience's state of mind 😆 (when writing documentation, I should add).

Professional technical writing is such an under-appreciated skill, I’ve found.

it's running a Clojure program with a different classpath the program you're executing

specifically, it's running tools.deps to compute the classpath based on your deps.edn (talking to Maven, maybe S3, maybe Git, etc). in the end it spits out the results in cache. Your actual program is then started with the classpath you intended. Once we've cached that work, we can spit the first part and just run the program.

So the advantage of caching based on the deps.edn file, rather than the classpath it contains, is all the I/O to talk to Maven, S3, git, etc.?

well, that's all of the work. not much point to caching otherwise

expanding and downloading a full deps tree can easily mean dozens of jars and many megabytes of network traffic (if your m2 and/or git cache is cold)

even if you have all the jars, expanding the tree is more than you'd want to wait, example in tools.deps.alpha repo (~80 jars in the full tree), all jars in cache so no downloads:

amac:tools.deps.alpha alex$ time clj -Sforce -e nil

real	0m3.028s
user	0m12.567s
sys	0m0.756s
amac:tools.deps.alpha alex$ time clj -e nil

real	0m0.745s
user	0m1.647s
sys	0m0.133s

(one caveat here is that the clj uber jar is not currently aot compiled - that's coming soon and will improve that first time, which includes a lot of loading)

but it's still not time anyone wants to wait

Hey guys. If i have a setup as described in https://clojure.org/guides/deps_and_cli#_using_local_libraries. is there a way to fire up a repl in the hello project which reloads the time-lib deps if they are changed?

with a cold m2 cache, time is about 7.5 s (aot may knock a couple seconds off that)

no, that's not a built-in feature of Clojure (or Java). there are ways to do some variants of this but it's not common

well, do you mean local dir or local jar?

if local dir, you can just use Clojure's normal :reload or :reload-all mechanism built into require

i meant local dir

yeah, so that's just normal reloading

ok. cool. thx

any idea why running brew upgrade clojure/tools/clojure installs 1.10.1.561 not 1.10.1.590 ?

561 is the newest stable release

590 is a dev release

I can see why that approach will be faster, though it breaks down (cache becomes stale) in the presence of dependencies that are expressed using a “floating” version reference (RELEASE, LATEST, SNAPSHOT, etc.). Those were deprecated in Maven3, and perhaps tools.deps should follow suit and emit a warning when it encounters such a thing?

perhaps

Following up from my comment in the announce thread:

{:paths [:clj-paths :resource-paths]
 :aliases
 {:clj-paths ["src/clj" "src/cljc"]
  :resource-paths ["resources"]}}

If that is correct, I don't see the value since they are fixed labels and values -- am I missing something @alexmiller?

oh, that is right - they are aliases

an alias is just a name for some data

this was the original meaning here but we have kind of gotten off talking about things that way by tying it into clj's usage of alias data to affect classpath construction

OK, so how is that useful since they are just fixed values?

at the moment, it's not very useful

Also, you have this paragraph twice "Replace project environment ("tool")" -- one with plenty of detail, one with very little.

but if you had say, a build tool that wanted to also use a subset of paths it might be useful

;)

that's actually intentional - the first part is kind of an overview, and the second is more how the tool works with more detail

doing a lot of heavy editing on this page lately but will likely change more over time

OK, I think it's just really confusing at the moment with two identical headers...

The Maven install example is missing an alias tho' (even if the paths one isn't), yes?

{:aliases
 {:fn clojure.tools.deps.alpha.install/install
  ;; :args map could be provided but can pass on command line instead
  }}

I'm ok with that for the moment :)

the toc at the top side bar may make the structure more evident

I've gone through about 5 different structures for this page recently, and I don't think I'm done

That's meant to be executed with -X:some-alias (most people will pick -X:install I suspect)

ah, yes that is

I actually saw that late last night and forgot to fix

I'm curious as to why that ability surfaced as a built-in option, given that JAR files can already be used as :local/root deps?

it's not a built-in option, it's a built-in program

didn't seem big enough to make into its own thing, depended heavily on all the code in tools.deps, wanted it for dev-local, etc

Interesting...

serves as a good example :)

the plan is to shift some of the magic switches in clj over to just be programs you can -X

some of those might become built-in to the root deps.edn, not sure yet

On another wordsmithing issue: now that page refers to "tool" as something that might want to override :deps and/or :paths, this section name might be confusing (a different meaning of tools) https://clojure.org/reference/deps_and_cli#_clojure_tools_usage

yeah, I've been fighting that, haven't decided what to do about it yet

not enough words :)

it's like naming things is hard

Tools are just so useful 🙂

The install line you gave in the announcement doesn't seem to work

Error: No available formula with the name "clojure/tools/clojure@1.10.590" 
==> Searching for a previously deleted formula (in the last month)...
Error: No previously deleted formula found.
==> Searching for similarly named formulae...
Error: No similarly named formulae found.

That's from brew install clojure/tools/clojure@1.10.590

(after a brew uninstall clojure)

Should be 1.10.1.590

Ah, shoot

Edited

wow need to get my head around these new tools.deps features; they might make some stuff I’ve been planning to do completely redundant :thinking_face:

how is the -T alias different to having an alias with a :deps key?

It’s not

I need to figure out how to get the clojure script updated on a couple of our older servers since this would help eliminate some of the extra script stuff we've written (but I think there's a blocker for installing clojure on a couple of our old servers).

It is exactly what was already there via -A, just has its own switch now

ok so it just makes the intent clearer on the command line?

Yep

A is meant to be an “all” kind of thing but this didn’t have its own name, so now it does

so what would -T do with :extra-deps instead of :deps?

(Which also helped further clarify some things in the code which has gone through some substantial changes)

It would be ignored

wow I had no idea how many deps had unqualified names. I thought it was just a handful, but it’s way more than I expected

Each of the sub processes takes what it expects and ignores the rest, like all good Clojure programs :)

Should this check include tools_aliases now?

-h|--help|"-?")
      if [[ ${#main_aliases[@]} -gt 0 ]] || [[ ${#all_aliases[@]} -gt 0 ]]; then
        break
      else
        help=true
        shift
      fi
      ;;

No?

Maybe I'm just missing the actual flow of the script then, nm.

Yeah this has to do with falsely interpreting a -h appended to main aliases as a help opt

(I was just grepping for (tool|all).alias through the new script out of curiosity)

Would be curious if you try the win install :)

@alexmiller re: -h -- that means that clojure -A:test:runner -h and clojure -T:test:runner -h behave differently.

(! 1537)-> clojure -T:test:runner -h|more
Version: 1.10.1.590

...
(! 1538)-> clojure -A:test:runner -h|more
Unknown option: "-h"

(the first case displays help -- -h is not passed to the main program; the second case passes -h to the main program in the test runner here)

Just tried doing -X:myfn in one of my projects and I get the error:

clojure -X:myfn
Execution error (FileNotFoundException) at clojure.main/main (main.java:40).
Could not locate clojure/tools/deps/alpha/exec__init.class, clojure/tools/deps/alpha/exec.clj or clojure/tools/deps/alpha/exec.cljc on classpath.

are you on clj 1.10.1.590?

I thought I was

yep

$ clojure --help
Version: 1.10.1.590

...

this is kind of a corner case - the condition is guarding against having -A/-M supplying the first part of the main args and then -h on the command line where it is not actually the main args to pass to clojure.main. I'm not worried about it.

I get that too, also on 1.10.1.590:

(! 974)-> clj -Sdescribe
{:version "1.10.1.590"
 :config-files ["/usr/local/Cellar/clojure@1.10.1.590/1.10.1.590/deps.edn" "/Users/sean/.clojure/deps.edn" "deps.edn" ]
 :config-user "/Users/sean/.clojure/deps.edn"
 :config-project "deps.edn"
 :install-dir "/usr/local/Cellar/clojure@1.10.1.590/1.10.1.590"
...
(! 975)-> clj -X:example
Execution error (FileNotFoundException) at clojure.main/main (main.java:40).
Could not locate clojure/tools/deps/alpha/exec__init.class, clojure/tools/deps/alpha/exec.clj or clojure/tools/deps/alpha/exec.cljc on classpath.

Full report at:
/var/folders/p1/30gnjddx6p193frh670pl8nh0000gn/T/clojure-13599808261801984368.edn
(! 976)-> cat deps.edn 
{:aliases
 {:example
  {:fn clojure.core/println
   :args {:n 1}}}}
(! 977)-> 

if you clj -Sdescribe and then jar tf <the-install-dir/clojure-tools-1.10.1.590.jar | grep exec.clj

do you see it?

what installer are you using?

the jar is further down than that in /usr/local/Cellar/clojure@1.10.1.590/1.10.1.590/libexec/clojure-tools-1.10.1.590.jar

sorry, bad multi copy/paste on my part, that's right

exec.clj is in there yes

this is mac? linux?

$ jar tf /usr/local/Cellar/clojure@1.10.1.590/1.10.1.590/libexec/clojure-tools-1.10.1.590.jar  | grep exec.clj
clojure/tools/deps/alpha/exec.clj

mac

(yup, same here)

brew was the installer

clj -Sdeps '{:aliases {:myfn {:fn clojure.core/pr}}}' -X:myfn is a standalone example

edn is broken

Fails for me

edn is broken means?

ah wait sorry was in a project with a broken edn file

(! 982)-> clj -Sdeps '{:aliases {:myfn {:fn clojure.core/pr}}}' -X:myfn
Execution error (FileNotFoundException) at clojure.main/main (main.java:40).
Could not locate clojure/tools/deps/alpha/exec__init.class, clojure/tools/deps/alpha/exec.clj or clojure/tools/deps/alpha/exec.cljc on classpath.

Full report at:
/var/folders/p1/30gnjddx6p193frh670pl8nh0000gn/T/clojure-12219293780956477884.edn

ah, I was able to repro

$ clj -Sdeps '{:aliases {:myfn {:fn clojure.core/pr}}}' -X:myfn
Execution error (FileNotFoundException) at clojure.main/main (main.java:40).
Could not locate clojure/tools/deps/alpha/exec__init.class, clojure/tools/deps/alpha/exec.clj or clojure/tools/deps/alpha/exec.cljc on classpath.

Full report at:
/var/folders/ln/536xqskd3_g80n5pdbsjkrjw0000gn/T/clojure-8308868078358895829.edn

too

it matters whether you're in a directory with a deps.edn

well, that's definitely a bug :)

will fix

thx

Crashes for me whether there's a deps.edn file or not.

yeah same

hm, maybe it's a cached classpath for me or something

there are 3 hard things in computer science…

I tried it via an alias in a deps.edn file (shown above), then tried via the command line with just {} in deps.edn, and then tried in a directory with no deps.edn -- all of them crash the same way. Even tried -Sforce and it still failed.

I tried two of those; just tried with -Sforce too — and same

well, that's weird. :) I've been using this for a while and others have tested it as well, somehow never saw an error

I'm sure it will make sense when I understand why it's doing it ... this is why it's a dev release!

Fair enough. Just wanted to point out that it is a difference between -A and -T 🙂

-X has to go at the end, in case that affects anything you tried

nope, I had -X as my only alias

Well I’d be happy to try and help narrow debug it but I’m afraid I need to call it an evening 😞 I’ll check back here tomorrow. Thanks for your help, and also thanks for the feature… it looks like it’ll be really useful.

ah, this makes sense to me now, and why it worked for me

and why things others tried worked. such a combination of coincidences... anyhow will fix

Now I'm curious, what's the bug?

it's not putting that class on the classpath, obviously :)

I was testing in the tools.deps.alpha repository itself

where it is

and others were testing things that used the install program, which requires you to pull in tools.deps.alpha

so those all worked

I may actually have flubbed a merge somewhere

there's no difference in how :deps and :paths work, which is what I meant

@seancorfield @rickmoynihan ok, new clj 1.10.1.596 is available, should fix this

Looks fixed! Thank you!

if you try it on windows (or linux), would be happy to hear there too

@vlaaad If you want to get strings from the command line in your -X-executed function, you can always use *command-line-arg* (although you'd have to discard leading arguments passed to the CLI itself I guess)

(! 1010)-> clj -A:test -X:example :test value
("-X:example" ":test" "value") ({:test value})

I don't want to make every arg a string 🙂

How would you want the CLI to distinguish between "I want this as a string" vs "I want this as an EDN value"?

It seems like you'd have to try to read as EDN and if you got an error or a symbol then use the whole argument as a string, else whatever the EDN reader produced? Which is open to all sorts of surprises I would expect...?

I guess it's impossible to have it both simple and easy 😞

I don't want to deal with escaping because I use both powershell and bash that have different escaping rules. With those, whenever I have a need to escape I wish I just used a file. This might be a bit too limiting for convenience, but I'd be fine with this: everything that can be read as number/boolean/keyword/nil -> number/boolean/keyword/nil everything else, including things that can be read as collections -> string

it doesn't work with repeated args though

I've been thinking a bit more about simple vs easy, and currently I think I'm overreacting, I think escaping might be an okay price to pay for the limitations different approaches provide

when you have static data, the best thing to do is put it in deps.edn and reference via alias

> including things that can be read as collections -> string I think that's a bad idea since it's common to want to pass a map of stuff when calling Clojure function (in general) so that choice would force EDN parsing on everyone

with -X you are always passing a map - the command line is overrides to the data in deps.edn

and the overrides support nested paths

Right, I meant as one of the arguments (inside that map)

nested paths gets you out of another set of cases

i.e., to produce a nested map

like -X:deploy :envs '#{"prod" "qa"}'

Yeah, having :test 1234 and :test [1234 5678] produce a number and a string respectively would be very strange.

I agree 🙂

it turns out vectors are actually ok bash if you use the comma

not ok pwsh

:test [1234,5678] is actually ok

I sympathize with the additional pain on PS (I too use it from time to time with the Clojure CLI) but since the vast majority of Clojure CLI users are on macOS/Linux I'd rather not make all their lives more painful, just to make PS less painful -- and it's already a bit painful to use for the Clojure CLI...

maybe this is a topic for #clj-on-windows but what's the story on the new Windows terminal?

hmm, I might be tripping, [1,2,3] worked fine in pwsh

@alexmiller The new Windows terminal is just a fancy tabbed shell around existing PS, cmd, and Linux terminals.

so nothing new

out of curiosity, why are unqualified lib names now deprecated? was there a deeper issue that needed addressing or is it just because qualified names are unambiguous and more correct?

https://clojurians.slack.com/archives/C06MAR553/p1595944089258600?thread_ts=1595943934.258100&cid=C06MAR553

ah

and clj -X:example [:test,:value] 1234 works on macOS so, yay, portability! 🙂

I saw it in the blog post that he posted https://insideclojure.org/2020/07/28/clj-exec/

which mentioned the deprecation again, but I was curious if there was a deeper reason for it

not sure what I can add beyond what's in the blog

unqualified names are bad so we're going to stop encouraging them in this area

that makes sense, thank you

PS C:\Users\Vlaaad\Projects\tdeps> cat .\deps.edn
{:aliases {:prn {:fn clojure.core/prn}}}
PS C:\Users\Vlaaad\Projects\tdeps> clj -Sdescribe
{:version "1.10.1.596"
 ..."}
PS C:\Users\Vlaaad\Projects\tdeps> clj -X:prn
Execution error (FileNotFoundException) at clojure.main/main (main.java:40).
Could not locate clojure/tools/deps/alpha/exec__init.class, clojure/tools/deps/alpha/exec.clj or clojure/tools/deps/alpha/exec.cljc on classpath.

hrm, let me check on that, shouldn't be using that class anymore

-Spath is

C:\Users\Vlaaad\.m2\repository\org\clojure\clojure\1.10.1\clojure-1.10.1.jar;C:\Users\Vlaaad\.m2\repository\org\clojure\spec.alpha\0.2.176\spec.alpha-0.2.176.jar;C:\Users\Vlaaad\.m2\repository\org\clojure\core.specs.alpha\0.2.44\core.specs.alpha-0.2.44.jar;src

path is fine, it's the class, I missed one change there

windows 1.10.1.600 has the fix

To encourage use of groupid

And discourage hiccup/hiccup in favor of com.weavejester/hiccup. But in a general sense, not the global sense.

Does -X compose?

What do you mean by that?

depends what you want to compose with :)

with other -X, no

with all the classpath stuff, yes

but if you want to run multiple things, write a program that does so and run it with -X :)

Finally 🙂 That was one thing that always made me wonder why one would have unqualified library names when clojure is so heavily rooted in java.

I don't want to write lots of programs! I want to change my programs on a whim at the cli. Start a socket server, start a whatever, run the program in the local project that does setup, run my custom dev function.

(We've discussed before though, not really trying to convince, but I hoped that exec would provide this)

Right now I'm (ab)using the fact you can supply an init and a main to load a dev.clj in my home directory, which will run things based on the directory the jvm started in...

there's this thing called a repl that lets you do like ... anything

Yeah, but I have to like type all these weird ( characters.

PS C:\Users\Vlaaad\Projects\tdeps> clj -Sdescribe
{:version "1.10.1.600" ...}
PS C:\Users\Vlaaad\Projects\tdeps> clj -X:prn
Execution error (ExceptionInfo) at clj-exec/check-first (clj_exec.clj:32).
Invalid first arg to exec: prn

could it be PS escaping away the :? :thinking_face: other args like -A:alias work fine thogh

In earnest, there's a little bit of a desire to hide implementation behind flags. Telling someone to run clojure -A:nrepl:piggieback is easier than explaining that they need to run a set of functions once waiting for the repl to connect, and then press buttons on their editor, in an exact sequence to make it work. Right now I use jvm options.

will take a look, not sure

maybe I'm missing the first arg I match in the pwsh for this, but seems like we'd get nothing here, not part of the arg

how hard is it for you to just modify the ClojureTools.psm1 ?

I think line 84 just needs to be $ExecAlias += $arg, $params

it's losing the matching $arg right now

Dang, we use a lot of single-segment lib names at work! 😞

(updating 27 deps.edn files in our monorepo!)

I have https://www.youtube.com/watch?v=jsW9MlYu31g running through my head ...

feedback on the warning message? I tried to make it useful

Am I right in thinking the new "alias data" feature is going to allow people to add all sorts of configuration stuff into deps.edn as data under an alias?

if they like

Folks have been asking for that for quite a while 🙂

like most things, taste is helpful

(and have been told in the past, "don't do that" 🙂 )

it might be a good place to put like, build configuration

Hmm, and because aliases don't compose, it's "just" fixed data so I guess that's a nice place to draw the line.

I suspect shadow-cljs and other tools might leverage it for build config to avoid having a separate file for that...

It's perfect.

Annoying, but perfect.

The only slightly weird thing was that I seemed to get all of the warnings twice?

Aliases can compose, but it's down to their interpreter to decide how.

btw, I don't know if add-libs works with latest (haven't tried). I am still injecting the lib map atm which is what add-libs works starts from, but not sure if it also uses anything else in tools.deps that's changed. the branch I have has the stuff to switch to basis but also other stuff too so some interpolation will need to be done, not sure when I'll get to that

NP. I just updated my dot-clojure deps.edn to rename the alias from :deps to :add-lib and add notes that it should be considered experimental and likely to break or go away 🙂

(I had forgotten that the installed deps.edn contains a :deps alias when I originally added it)

I also just cleaned up the :rebl* aliases to reflect the latest REBL having its own deps.edn files for java8 and openjfx15ea (plus some reorganization and updating several versions).

cool

that dimly rings a bell. I wrote this like a month ago. I think because it's encountered during canonicalization and also during expansion or something?

My work is now finally using deps.edn/tools.deps/clojure CLI (how do you even call this stuff?). I moved out our front-end build to it (using figwheel.main / cljs.main) last week while we still do the uberjar and REPL stuff with boot. Also now we can finally run Java 11 everywhere, since we were stuck, the boot frontend stuff didn't work with it (at least not for us).

that's exciting @borkdude

nice!

Also we use this dev script to start 3 processes simultaneously: clojure -A:cljs/dev, clojure -A:less/dev and ./boot dev, while having only one terminal tab open: https://gist.github.com/borkdude/8f5dff7c2330ca520403eb44c9013a83, just as a convenience

3 jvms! I bet that doesn't integrate well with cider jack in. Might I suggest starting 3 threads instead?

I've always avoided cider-jack-in, I always use cider-connect. Even more so now I'm developing on a remote machine but editing files in my local emacs using tramp.

Threads may work but it's not a huge deal right now. We need at least two JVMs given we're using two different build/classpath/dependency tools right now.

"I've always avoided cider" -- ftfy 🙂

As part of this monorepo deps cleanup I'm doing (to prevent all those DEPRECATED warnings!) I'm also removing the last few references to nREPL in our setup since neither I nor my team mate use that now.

seems unfair to people who use jack in. ¯\(ツ)/¯

Well, I asked my teammates and this was all OK for them, so I guess we're good 🙂

I’m curious why the new tools.deps adds a tool to do local maven installs. Is this something people frequently need? I’ve probably only ever needed to install free form jars into my local maven repo a few times in the past ten years. I mean sure if I’ve built a jar myself I will frequently want to install it, but it seems strange to supply a method to install jars, but not build them. I’m just curious what problem it’s solving for people.

Am I missing something in my workflow; or is it just that this happens to have been baked before other build tasks in tools.build?

works now! Thanks 🙂

Perhaps related to Datomic's dev-local needing to be installed into your local Maven repo to be used (it's not distributable).

^ That is what Alex said when asked earlier @rickmoynihan

ahh ok makes sense in that use case. Thanks @seancorfield

thx

@alexmiller Robot Chicken has some pretty darned funny riffs on Star Wars scenes, including the one you linked above: https://www.youtube.com/watch?v=WpE_xMRiCLE