{:aliases {:foo ["bar"]}} and clj -A:foo produces interesting results :P e.g.

:resolve-args {\b \a},
:classpath-args {\b \a},

I was curious to see what would happen :)

Hi! What is the relationship of versions between Clojure and tools.deps? Latest Clojure download is https://download.clojure.org/install/linux-install-1.10.1.727.sh, latest https://github.com/clojure/tools.deps.alpha#release-information. If I install that Clojure, which deps will I get? I.e. what command-line options will clojure support? Thank you!

The change logs for the two are cross linked and you can find official release info at https://clojure.org/releases/tools

The docs on the Clojure site always reflect the latest stable release (or use -h or the man page)

https://clojure.org/reference/deps_and_cli

Thank you! I should have noticed the " See the changelog for version information." at https://clojure.org/guides/getting_started

Q1: Does :local/root need to be an absolute path? If so - I guess it isn't possible to use something like "~/path/to/it" (to make it portable across users)?

Q2: Why am I getting > Error building classpath. No coordinate type found for library cryogen-asciidoc/cryogen-asciidoc in coordinate {:local-root "/Users/me/external/cryogen-all/cryogen-asciidoc"} when head /Users/me/external/cryogen-all/cryogen-asciidoc/pom.xml returns successfully (modified)

...
  <groupId>cryogen-asciidoc</groupId>
  <artifactId>cryogen-asciidoc</artifactId>
...

https://github.com/lambdaisland/chui/blob/master/deps.edn#L4 is an example of relative paths. I think if you use an absolute path like ~/some/path it will not be portable at all

You can’t use ~ - that’s a shell thing

But either absolute or relative are fine

Not sure if that solves your q2 or not but if not share your deps.edn

I’m surprised you can’t use ~. I figured it would end up in a path object and the jvm would work it out for you

jvm doesn't do this

it's a bash thing. On Windows this doesn't work either

Makes sense. Not sure where I got that expectation

What could work OS-independent is interpolation of environment variables. But even then you would have to use different names for linux and windows

so probably a script that generates deps.edn for you as a pre-processing step is the least worst way of dealing with such concerns

I haven't had an app where I did this, except for one where I keep deps in sync between project.clj and deps.edn

Java has a system property for this - user.home

(System/getProperty "user.home") is platform independent

but no equivalent to that in deps.edn (yet, or maybe ever)

@holyjak what's the home-relative use case?

I would love to see deps.edn support some type of user home substitution. I have the a main $HOME/.clojure directory, in there I have my deps.edn file, that I pull in other libraries with that are all local root (i.e., setting up a REPL with some middleware etc..). Right now, since I’m on Linux I have to put an absolute path in, i.e., :base {:extra-deps {local-base/local-base {:local/root "/home/david/.clojure/libs/local.base" :deps/manifest :deps}}

I cannot bring that across to my mac environment

since that is /Users/home/david

I thus have to maintain two separate deps.edn files that are near identical, apart from the path stuff.

but and I’m just trying this out…having it as a relative path may work!

i.e., :base {:extra-deps {local-base/local-base {:local/root "libs/local.base" :deps/manifest :deps}}

nope

Switching to a relative path, ends up with

Execution error (FileNotFoundException) at clojure.main/main (main.java:40).
Could not locate local/rebel/main__init.class, local/rebel/main.clj or local/rebel/main.cljc on classpath.

which leaves me with having to put the absolute path in my deps.edn, and maintaining two separate deps.edn (which I suspect, if I was also on windows would incur more mangement)

It would be nice IMHO if deps supported at least having :local/root resolve the user’s home.

Hmm, I'm slightly surprised that resolution isn't relative when doing that. The personal tooling case is the only one I have so far too :)

I’m not, that’s what I’d expect - top level deps are relative to where you’re running clj

@alexmiller I suppose they could be resolved with a relative *dir* like when doing transitive :local/root though?

(obviously there's problems there due to the merging)

Yeah, that’s problematic

I suppose paths could be canonicalized pre-merging.

that's what I do in clj-kondo config. Each config can refer to local dirs relative to itself and these get resolved during config reading.

this way you can have hooks in your home dir config, not relative to your project

That’s possible, I’ll think about it

that would be nice

🙂