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

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 🙂 )

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

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:

omg...

@alexmiller I just installed 1.11.1.1139 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)

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...

That seems just as likely to be wrong

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

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.