Fork me on GitHub

Anyone hit an error while trying to use -M flag in Windows? Is it a known issue?


I just realize that if I do clj -Mother it fails. But doing clj -M:other works as expected


The latter is the expected syntax


Oh, so I'm guessing I always should prepend : in Windows. I always skip the first : in Linux

Alex Miller (Clojure team)20:06:18

don't - that's not supported


all aliases names should start with a : , if they don't then its not the name of an alias - there are many examples here Only -T tool names are free from : (although I use aliases for tools to give more configuration options)


Oh I see, if I use clj -Mother still picks up the :main-opts option, that's what confused me. I'm always prepending : form now on, thanks guys!


Some versions of the Clojure CLI did still work if it was missed of, but it's definitely a bug Some projects also included the incorrect command in their docs, so it's an easy trap to fall into... But it's definitely a trap :)

🙏 1

Is dont suppose there is a way to use an environment variable as part of the path when setting the path value for :mvn/local-repo in a deps.edn file? At least not without pre-processing the deps.edn file and re-writing with the value of the environment variable For example :mvn/local-repo "$XDG_CACHE_HOME/maven/repository I am assuming it needs to be a full path, as the above creates a directory called $XDG_CACHE_HOME in the current directory (of course 🙂 )

Alex Miller (Clojure team)20:06:19

that's not currently supported in a deps.edn file

Alex Miller (Clojure team)20:06:58

you could probably make it work passing on the command line with -Sdeps (but quoting is fun)


@jr0cket That's where I usually use -Sdeps if it's something dynamic


Okay, using -Sdeps makes sense as a command line configuration approach. For the particular :mvn/local-repo , ideally it would live in the user level deps.edn, but using a full path is only a slight inconvenience when sharing that setup as part of practicalli/clojure-deps-edn - I’ve just shared it for now with that configuration key commented (so I just have to remember not to over-ride it when committing new changes 😄 ). Thank you.


Maybe it also accepts a relative path? Assuming that in your user deps.edn, the relative path to a user .m2 dir can be relatively(!) well predicted? EDIT: well, that's not going to work, since it would be relative to the working directory


Yes, :mvn/local-rep will use a relative path, but it will be relative to where the clojure executable command is run. You can have some great fun setting :mvn/local-repl ~/.cache/maven/repository as it will create a directory called ~ in the directory where clojure was run, which under no circumstances should you delete using rm -rf ~ unless you have everything backed up in your home directory and you want a clean start :rolling_on_the_floor_laughing:


@alexmiller I just installed via the Linux installer and tried the install-latest function to update installed tools: it loses the :deps/root key when it upgrades:

diff --git a/tools/poly.edn b/tools/poly.edn
index 46da562..108a51a 100644
--- a/tools/poly.edn
+++ b/tools/poly.edn
@@ -1,5 +1 @@
-{:lib io.github.polyfy/polylith,
- :coord
- {:git/sha "f0d38cb71e9d3f7a620a4baecb491da4aab91edd",
-  :deps/root "projects/poly",
-  :git/url ""}}
+{:lib io.github.polyfy/polylith, :coord {:git/tag "v0.2.14-alpha", :git/sha "e874e80"}}


(never mind that it "updates" the latest master SHA to an earlier release tag and sha)

Alex Miller (Clojure team)22:06:04

In both cases, there's no way for it to know those things


If the existing, installed EDN file includes :deps/root, it could at least preserve it...

Alex Miller (Clojure team)22:06:59

That seems just as likely to be wrong

Alex Miller (Clojure team)22:06:47

Installing from latest version will always use a tag, so the master sha thing is not a version that's considered

Alex Miller (Clojure team)23:06:25

So this process won't work in all possible cases


So tools that require :deps/root cannot be safely installed or updated via install-latest? Perhaps that caveat could be added to the docstring and/or docs somewhere.


I'll have to make sure the Polylith docs include a warning not to use install-latest. Issue created in the Polylith repo.