Clojure Q&A - Recent questions tagged tools.deps Is it possible to build an uberwar using deps.edn using or other tool? <p>We have a small Clojure &amp; ClojureScript web app running in Tomcat. The project managed to end up with a deps.edn for use with Shadow-cljs &amp; lein for the backend to essentially build an uberwar. Is there a way to build an uberwar with tools-build or in some other way using deps.edn?</p> <p>Thanks for any pointers</p> <p>Cheers<br> Daniel Sunnerek</p> Clojure Thu, 02 Dec 2021 13:22:01 +0000 tools.deps - How do I list dependencies and their versions from the REPL? <p>I want to check which version of some dependencies I have loaded in the project from the REPL. Can it be done? How do I do this, if so?</p> <p>The project I am working with is started via a rather involved script, making it a bit hard to know what version of certain dependencies are eventually loaded. I am thinking that once I have a REPL, then I have the truth. </p> <p>It's a tools.deps project</p> REPL Thu, 11 Nov 2021 11:47:04 +0000 Allow absolute paths for file-based Git URLS <p><strong>Type:</strong> Enhancement<br> <strong>Summary:</strong> Expand <code>tools.gitlibs</code> support for local Git URLs<br> <strong>Description:</strong><br> When specifying a local file-based URL for a Git repo containing a dependency, I encounter the following error when using an absolute URL:</p> <p><code>`</code></p> <p>java.lang.IllegalArgumentException: /path/to/my/repo is not a relative path</p> <pre><code> at$as_relative_path.invokeStatic(io.clj:414) at$file.invokeStatic(io.clj:426) at$file.invoke(io.clj:418) at clojure.lang.ArraySeq.reduce( at clojure.core$reduce.invokeStatic(core.clj:6829) at$file.invokeStatic(io.clj:418) at$git_dir.invokeStatic(impl.clj:59) at$ensure_git_dir.invokeStatic(impl.clj:80) at$procure.invokeStatic(gitlibs.clj:61) at$fn__1317.invokeStatic(git.clj:98) at$fn__1317.invoke(git.clj:96) at clojure.lang.MultiFn.invoke( at$expand_deps.invokeStatic(alpha.clj:425) at$resolve_deps.invokeStatic(alpha.clj:495) at$calc_basis.invokeStatic(alpha.clj:738) ... </code></pre> <p><code>`</code></p> <p>The requirement of relative URLs makes specifying dependencies more difficult in certain contexts - the specific motivating use case for me is a WSL environment where the Clojure process is running in Ubuntu/WSL but the source code is in the Windows filesystem.</p> <p>Alex Miller mentioned on the Clojurians Slack when I mentioned this problem that "that's really a subset of the problem - the code that translates git urls to cache dirs and libs doesn't handle either raw paths or relative urls."</p> tools.gitlibs Fri, 05 Nov 2021 19:24:15 +0000 Using a git SHA for a local git dependency? <p><strong>Type:</strong> Enhancement</p> <p><strong>Summary:</strong> Use git SHAs + tags for local deps</p> <p><strong>Description:</strong></p> <p>Currently, when working with local dependencies, I cannot use a git tag to refer to a specific revision of a project. <code>:local/root</code> only respects the current version of the working tree, which can make using local deps under active development a bit trickier. </p> <p>Support for SHAs and tags for local projects which are specified via file-based Git URLs would allow projects consuming local deps to specify the state of those projects unambiguously.</p> <p>I previously asked a version of this question on the Clojurians slack and was referred here by Alex Miller.</p> tools.deps.alpha Fri, 05 Nov 2021 19:12:28 +0000 :deps in dependency not (always) working when there is no :path specified in dependency <p>Similar to this question <a rel="nofollow" href=""></a></p> <p>I am not sure how to reliably reproduce this, but I had a problem with dependencies not being picked up from a <code>:local/root</code> dependency, and my colleague found the linked question, and it helped me find a workaround.</p> <p>In my case my full deps in the dependency project was:</p> <pre><code>{:paths ["src"]} </code></pre> <p>Changing it to:</p> <pre><code>{:paths ["src"] :deps {}} </code></pre> <p>made things work.</p> <p>I do have another project with the same dependency, and it was happy with the no-deps version.</p> <p>This was in a dependency of a dependency. So I have both these cases:</p> <ul> <li><strong>Not working</strong>: <code>project-a</code> -&gt; -<code>dependency-1</code> -&gt; <code>dependency-2-path-only</code> </li> <li><strong>Working</strong>: <code>project-b</code> -&gt; -<code>dependency-1</code> -&gt; <code>dependency-2-path-only</code> </li> </ul> <p>(”Not working/Working” as in <code>dependency-2-path-only</code> not being on the classpath of <code>project-a</code>, but on the classpath of <code>project-b</code>.)</p> <p>Further... <code>dependency-1</code> is in a sub directory of <code>dependency-2-path-only</code>. So in <code>dependency-2-path-only/dependency-1/deps.edn</code>:</p> <pre><code>{:paths ["src"] :deps {d2/dependency-2-path-only {:local/root ".."}}} </code></pre> <p>I realize now, after having described all this that I could have made a repro instead. Let me know if that is needed.</p> <p>I'm currently on, btw.</p> tools.deps.alpha Tue, 26 Oct 2021 08:42:30 +0000 uber task fails when the dependency tree contains a dep which has no jar <p>The <code></code> task fails when the dependency tree contains a dep which has no jar. </p> <p>A relatively minimal failing test case is the following task:</p> <pre><code>(ns build (:require [ :as b])) (defn failing-uber [_] (b/uber {:class-dir "classes" :uber-file "foo.jar" :basis (b/create-basis {:project {:deps {'org.apache.jena/apache-jena-libs {:mvn/version "4.2.0" :extension "pom"} }}})}) (comment (failing-uber {}) ) </code></pre> <p>Evaluating the above function results in the following exception:</p> <pre><code>1. Unhandled clojure.lang.ExceptionInfo Unexpected lib file: /Users/rick/.m2/repository/org/apache/jena/apache-jena-libs/4.2.0/apache-jena-libs-4.2.0.pom {} uber.clj: 182 uber.clj: 141 uber.clj: 257 343 clojure.lang.PersistentVector/reduce core.clj: 6829 clojure.core/reduce core.clj: 6812 clojure.core/reduce uber.clj: 256 protocols.clj: 49 clojure.core.protocols/iter-reduce protocols.clj: 75 clojure.core.protocols/fn protocols.clj: 75 clojure.core.protocols/fn protocols.clj: 13 clojure.core.protocols/fn/G core.clj: 6830 clojure.core/reduce core.clj: 6812 clojure.core/reduce uber.clj: 254 uber.clj: 241 384 clojure.lang.Var/invoke api.clj: 394 api.clj: 339 REPL: 21 build/eval25043 REPL: 21 build/eval25043 7181 clojure.lang.Compiler/eval 7136 clojure.lang.Compiler/eval core.clj: 3202 clojure.core/eval core.clj: 3198 clojure.core/eval interruptible_eval.clj: 87 nrepl.middleware.interruptible-eval/evaluate/fn/fn 152 clojure.lang.AFn/applyToHelper 144 clojure.lang.AFn/applyTo core.clj: 667 clojure.core/apply core.clj: 1977 clojure.core/with-bindings* core.clj: 1977 clojure.core/with-bindings* 425 clojure.lang.RestFn/invoke interruptible_eval.clj: 87 nrepl.middleware.interruptible-eval/evaluate/fn main.clj: 437 clojure.main/repl/read-eval-print/fn main.clj: 437 clojure.main/repl/read-eval-print main.clj: 458 clojure.main/repl/fn main.clj: 458 clojure.main/repl main.clj: 368 clojure.main/repl 137 clojure.lang.RestFn/applyTo core.clj: 667 clojure.core/apply core.clj: 662 clojure.core/apply regrow.clj: 20 refactor-nrepl.ns.slam.hound.regrow/wrap-clojure-repl/fn 1523 clojure.lang.RestFn/invoke interruptible_eval.clj: 84 nrepl.middleware.interruptible-eval/evaluate interruptible_eval.clj: 56 nrepl.middleware.interruptible-eval/evaluate interruptible_eval.clj: 152 nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn 22 clojure.lang.AFn/run session.clj: 202 nrepl.middleware.session/session-exec/main-loop/fn session.clj: 201 nrepl.middleware.session/session-exec/main-loop 22 clojure.lang.AFn/run 825 java.lang.Thread/run </code></pre> <p>I believe this is because the above dependency has no corresponding jar file, and only contains a pom.xml which groups up a set of dependencies.</p> Tue, 12 Oct 2021 14:00:42 +0000 Resolve git deps via artifactory <p>As a follow up to <a rel="nofollow" href=""></a></p> <p>Given the increasing usage of git deps (eg it is increasingly painful to use in corporate environments without direct github access. The majority of such corporates use tools like artifactory which, other than proxy things like maven, also allow proxying GitHub. </p> <p>Specifically it allows access, via an API, that will download a specific sha or tag from github as a zip/tar archive. </p> <p>In a general sense, could tools.deps be augmented to support this use case? I can see a few scenarios:</p> <ol> <li>Provide a remote/root or remote/archive that works similar to a local/root, but can source from an arbitrary zip/tar provided by a url</li> <li>Similarly allow git deps to resolve from some archive provided from a url</li> </ol> <p>Since the url will have the tag/sha in it, presumably tools.deps would not need to download it again unless the URL was changed. </p> tools.deps.alpha Wed, 15 Sep 2021 13:07:15 +0000 Should functions respect with-dir (from tools.deps.alpha)? <p>I ran across this issue with <code>depstar</code> but observed that <code></code> behaves the same, possibly incorrect, way.</p> <p>See <a rel="nofollow" href=""></a></p> <p>If you wrap <code>(b/create-basis ..)</code> in <code>with-dir</code> from <code>tools.deps.alpha</code>, it calculates the basis from the <code>deps.edn</code> file in the context of the <code>with-dir</code> location.</p> <p>However, if you use that basis with <code></code> functions, they do not behave correctly -- even if they are also wrapped in the same <code>with-dir</code> context.</p> <p>The dependencies come from the project <code>deps.edn</code> (Clojure 1.9.0 in this example) but the <code>src</code> used is from the root of the repo, not from the project folder.</p> <p>This is counter-intuitive (and took me a while to track down with <code>depstar</code> -- where I definitely consider it to be a bug).</p> Wed, 08 Sep 2021 22:02:10 +0000 Hope tools.deps.alpha add feature for listing available aliases <p>I think add an option for listing out available aliases will be helpful when there are many alaises.</p> <p>Here is my try. <a rel="nofollow" href=""></a></p> tools.deps.alpha Fri, 03 Sep 2021 07:54:40 +0000 Why tools-deps downloads all deps again when i run the tests (locally and on CI) <p>Hi,</p> <p>I am trying to download all deps so tests and other steps on CI should not do it.</p> <p>I run this command to download all deps<br> <code> clojure -Sdeps '{:mvn/local-repo ".m2"}' -A:dev:test:prod:frontend -Spath &gt; /dev/null</code><br> I can confirm <code>.m2</code> and <code>.cpcache</code> dirs are there.</p> <p>But when I run <br> <code>clojure -Sdeps '{:mvn/local-repo ".m2"}' -M:dev:test</code><br> All deps are being downloaded again.</p> <p>It reproduces locally and on ci.</p> <p>Sdescribe<br> <code>{:version "" :config-files ["/usr/local/Cellar/clojure/" "/Users/kirill/.clojure/deps.edn" "deps.edn" ] :config-user "/Users/kirill/.clojure/deps.edn" :config-project "deps.edn" :install-dir "/usr/local/Cellar/clojure/" :config-dir "/Users/kirill/.clojure" :cache-dir ".cpcache" :force false :repro false :main-aliases "" :repl-aliases ""}</code></p> Tools Thu, 02 Sep 2021 13:50:27 +0000 getting "Function not found" when invoking clojure with -X:alias <p>I have two aliases in my deps.edn:</p> <pre><code>{ :deps { org.clojure/spec.alpha {:mvn/version "0.2.194"} aleph/aleph {:mvn/version "0.4.7-alpha7"} hiccup/hiccup {:mvn/version "2.0.0-alpha2"} } :aliases { :web-server { :exec-fn :exec-args {:port 8080} } :test-web-server { :exec-fn test.tnetwork-service/run :exec-args {:port 9090} } } } </code></pre> <p>When invoking </p> <pre><code>clojure -X:web-server </code></pre> <p>I get </p> <pre><code>Function not found: </code></pre> <p>Everything is honky dory when invoking </p> <pre><code>clojure -X:test-web-server </code></pre> <p>I don't see why would that be, the exec-funs are basically identical. Take a look at full code here: <a rel="nofollow" href=""></a><br> I have <code>:paths ["." "src"]</code> in my global deps.edn</p> Tools Wed, 18 Aug 2021 16:07:57 +0000 Did TDEPS-187 break add-libs? <p>TDEPS-187 changed <code></code>, which now merges <code>argmaps</code> after <code>{:libs libs}</code> - <a rel="nofollow" href="">diff</a>.</p> <p>I'm running on tools deps at <a rel="nofollow" href="">this commit</a>, and I'm unable to add libs.</p> <p><code></code> calls <code>calc-basis</code> with <code>initial-basis</code> as the second argument, which means the <code>:libs</code> in initial basis replace those calculated by <code>calc-basis</code>.</p> <p>Switching the merge order to: </p> <p><code>`</code>clojure<br> (merge master-edn cp argmaps {:libs libs})<code> </code>``</p> <p>enables me to add libs to the classpath.</p> <p>Is this a regression, or am I holding it wrong?</p> REPL Thu, 12 Aug 2021 14:02:38 +0000 Support preparing :deps/:extra-deps in aliases <p>Right now there's no way to prepare dependencies only included as as <code>:deps</code> or <code>:extra-deps</code> in aliases with <code>clj -X:deps prep</code>. Adding support for an <code>:aliases</code> option that would prepare these be extremely helpful, e.g.</p> <p><code>clj -X:deps prep :aliases '[:my-alias]'</code></p> <p>Real-world use case: at Metabase we have a <code>:drivers</code> alias that adds several <code>:local/root</code> data warehouse driver subprojects to our classpath. For our Spark SQL driver we need to AOT a few <code>:gen-class</code> namespaces that we use as proxy JDBC drivers. Currently we have people run <code>clj -X:deps prep</code> in multiple directories; a way to pass aliases to prep would let us do this in a single command.</p> <p>JIRA Issue: <a rel="nofollow" href=""></a></p> tools.deps.alpha Sat, 07 Aug 2021 00:02:41 +0000 create-basis/java-command do not handle :jvm-opts <p>I have a <code>:test</code> alias in my project, which includes <code>:jvm-opts</code> (as well as <code>:extra-paths</code> and <code>:extra-deps</code>). I call <code></code> with <code>{:aliases [:test]}</code> and then pass that basis to <code></code> but that doesn't include those JVM options.</p> <p>In order to pick up those JVM options, I needed to do this:</p> <pre><code>(defn run-tests [_] (let [basis (b/create-basis {:aliases [:test]}) combined (t/combine-aliases basis [:test]) cmds (b/java-command {:basis basis :java-opts (:jvm-opts combined) :main 'clojure.main :main-args ["-m" "cognitect.test-runner"]}) {:keys [exit]} (b/process cmds)] (when-not (zero? exit) (throw (ex-info "Tests failed" {}))))) </code></pre> <p>(so I have to use <code>tools.deps.alpha/combine-aliases</code>).</p> <p>Is this expected? Should this be easier?</p> Tools Tue, 03 Aug 2021 04:31:20 +0000 Add support for BOM (Bill Of Materials) dependencies <p>Currently, if you have a dependency that is a BOM on Maven, you have to track down what all the components of that BOM are and list them as explicit, individual dependencies. It would save a lot of detective work and redundancy if t.d.a supported this type of dependency directly.</p> Tools Mon, 02 Aug 2021 17:08:00 +0000 help/doc doesn't work with project dependencies <p>Repro:</p> <pre><code>(! 748)-&gt; cat deps.edn {:deps {org.clojure/data.csv {:mvn/version "RELEASE"}}} (! 749)-&gt; cat src/foo.clj (ns foo "Example namespace." (:require [ :as csv])) (defn bar "Example function" [_] (println "Baaa!")) (! 750)-&gt; clojure -X foo/bar Baaa! (! 751)-&gt; clojure -X:deps help/doc :fn foo/bar Syntax error (FileNotFoundException) compiling at (foo.clj:1:1). Could not locate clojure/data/csv__init.class, clojure/data/csv.clj or clojure/data/csv.cljc on classpath. Full report at: /var/folders/p1/30gnjddx6p193frh670pl8nh0000gn/T/clojure-12591734153756667401.edn </code></pre> <p>Because <code>-X:deps</code> replaces the project dependencies, only the <code>src</code> files are found (because <code>:paths</code> is not replaced).</p> Tools Thu, 29 Jul 2021 17:14:04 +0000 What does "Manifest type :jar not loaded when finding deps ..." mean? <p>I have a jar that I created from one of my projects using <code></code>. I have included it has a <code>:local/root</code> dep in a different project but get the following error whenever I invoke <code>clj</code> with the jar on the classpath.</p> <p><code>Error building classpath. Manifest type :jar not loaded when finding deps for io.github.erp12/clark-scala in coordinate {:local/root "/Users/eddie/Projects/Software/clark/clark-scala/target/clark-scala-", :deps/manifest :jar, :deps/root "/Users/eddie/Projects/Software/clark/clark-scala/target/clark-scala-", :parents #{[]}, :paths ["/Users/eddie/Projects/Software/clark/clark-scala/target/clark-scala-"]}</code></p> <p>This error message helps identify which dep (and in this case, which exact jar file) is causing the problem, but I don't know if there is any information in there that could help identify the cause problem. Am I missing the way to interpret this exception? Are there any common causes of this?</p> Sun, 18 Jul 2021 06:16:17 +0000 git-resolve-tags doesn't support new format of git coords <p>With tools.deps v0.12.985+, the <code>:git/url</code> key is optional for git coords and the <code>:sha</code> and <code>:tag</code> keys are renamed to <code>:git/sha</code> and <code>:git/tag</code>, respectively. But <code>clj -X:deps git-resolve-tags</code> doesn't seem to support this new format of git coords yet.<br> This can be confirmed as follows:</p> <pre><code>$ cat deps.edn {:deps {org.clojure/clojure {:mvn/version "1.10.3"}} :aliases {:build {:override-deps {io.github.clojure/ {:git/tag "v0.1.3"}}}}} $ clj -X:deps git-resolve-tags Resolving git tags in deps.edn ... No unresolved tags found. $ </code></pre> <p>Whereas:</p> <pre><code>$ cat deps.edn {:deps {org.clojure/clojure {:mvn/version "1.10.3"}} :aliases {:build {:override-deps {io.github.clojure/ {:git/url "" :tag "v0.1.3"}}}}} $ </code></pre> <p>can be resolved successfully:</p> <pre><code>$ clj -X:deps git-resolve-tags Resolving git tags in deps.edn ... Resolved v0.1.3 =&gt; 688245ea6cc8b3b173b79b861938444fcd9e3e1e in $ </code></pre> <p>Probably, the following lines should be updated accordingly:</p> <ul> <li><a rel="nofollow" href="">resolve_tags.clj#L26</a></li> <li><a rel="nofollow" href="">resolve_tags.clj#L41</a></li> </ul> tools.deps.alpha Fri, 16 Jul 2021 13:30:54 +0000 Can :paths be symlinks that point outside the project? <p>If :paths contain a project-local symlink that points to a directory outside the project, TDA prints a warning like:</p> <p><code>WARNING: Use of :paths external to the project has been deprecated, please remove: resources</code></p> <p>In general, it's a good idea to warn about external dependencies, and if the :paths were, say, <code>["../untracked-src" "/tmp/misc"]</code> I'd be glad to see the warning.</p> <p>But in this case, my build is caching intermediate results on /tmp (mounted as tmpfs for speed among other things) and referring to them via project-local symlink which I didn't expect TDA to differentiate from a local dir.</p> <p>Say <code>deps.edn</code> is</p> <pre><code>{:paths ["resources"]} </code></pre> <p>and resources is a symlink</p> <pre><code>resources -&gt; /tmp/resources.FlkJvG </code></pre> <p>then it'd be nice not to see this warning.</p> <p>It seems the :paths validator chases symlinks as it canonicalizes paths before checking whether they're external. Perhaps it can be relaxed to normalize paths without chasing symlinks e.g.:</p> <pre><code>(in-ns ' (defn normalize "Make normalized File in terms of the current directory context without following symlinks. f may be either absolute or relative." ^File [^File f] (-&gt; (if (.isAbsolute f) f (jio/file *the-dir* f)) .toPath .normalize .toFile)) ;; and modify `sub-path?' to use `normalize' instead of `canonicalize'. </code></pre> tools.deps.alpha Wed, 14 Jul 2021 22:03:39 +0000 -X:deps help/doc does not work for a function <p>With a minimal <code>deps.edn</code>-based project:</p> <pre><code>(! 1105)-&gt; clojure -Tnew lib :name repro/help-doc Generating a project called help-doc based on the 'app' template. (! 1106)-&gt; cd help-doc/ (! 1107)-&gt; cat src/repro/help_doc.clj (ns (:gen-class)) (defn greet "Callable entry point to the application." [data] (println (str "Hello, " (or (:name data) "World") "!"))) (defn -main "I don't do a whole lot ... yet." [&amp; args] (greet {:name (first args)})) (! 1108)-&gt; clojure -X:deps help/doc :ns ------------------------- ([&amp; args]) I don't do a whole lot ... yet. ------------------------- ([data]) Callable entry point to the application. (! 1109)-&gt; clojure -X:deps help/doc :fn ------------------------- (! 1110)-&gt; cat deps.edn {:paths ["src" "resources"] :deps {org.clojure/clojure {:mvn/version "1.10.3"}}} </code></pre> <p>Neither of these work either:</p> <pre><code>(! 1111)-&gt; clojure -X:deps help/doc :ns :fn greet ------------------------- (! 1112)-&gt; clojure -X:deps help/doc :ns-default :fn greet ------------------------- </code></pre> Tools Tue, 13 Jul 2021 18:06:00 +0000 :deps manifest dependencies do not respect :mvn/repos in dependent project <h2>Problem</h2> <p>It's impossible to depend on a deps.edn-based project using git or local dependency when that project uses custom maven repos. Attempts to build classpath for projects depending on such projects will fail.</p> <h2>Repro</h2> <p>I created a minimal repo that illustrates the issue: <a rel="nofollow" href=""></a></p> <p>It contains 3 deps.edn projects: lib, app-local and app-git.</p> <p><a rel="nofollow" href="">lib</a> contains a single deps.edn file that defines a custom maven repo and a dependency that pulls from that repo.</p> <p><a rel="nofollow" href="">app-local</a> contains a single deps.edn file that defines a :local/root dependency on lib.</p> <p><a rel="nofollow" href="">app-git</a> contains a single deps.edn file that defines a :git/url dependency on lib.</p> <h3>Expected behavior</h3> <p>Running <code>clj -P</code> should succeed in lib, app-local and app-git projects.</p> <h3>Actual behavior</h3> <p>Running <code>clj -P</code> succeeds only in lib and fails in app-local and app-git with the error "Error building classpath. Could not find artifact net.sf.saxon:saxon-dom:jar: in central (<a rel="nofollow" href=""></a>)"</p> Tools Thu, 24 Jun 2021 09:18:22 +0000 Unable to parse tools.deps -Sdescribe output as EDN on Windows <p>I installed tools.deps on Windows using Scoop and it works nicely. However, when I do <code>clj -Sdescribe</code> I get the following output:</p> <pre><code>$ clj -Sdescribe {:version "" :config-files ["C:\Users\***\scoop\modules\ClojureTools\deps.edn" "C:\Users\***\.clojure\deps.edn" "deps.edn"] :config-user "C:\Users\***\.clojure\deps.edn" :config-project "deps.edn" :install-dir "C:\Users\***\scoop\modules\ClojureTools" :config-dir "C:\Users\***\.clojure" :cache-dir "C:\Users\***\.clojure\.cpcache" :force False :repro False :main-aliases "" :repl-aliases "" :exec-aliases ""} </code></pre> <p>and when I then try to parse this as EDN (which should be possible) via <code>clojure.edn/read-string</code> I get the error: <code>Unsupported escape character: \U</code> which obviously happens because the file path of <code>C:\Users\...</code> contains that.</p> <p>This would probably need to be adjusted by the tools.deps team? I could work around it, but in a general case, I'd have no way of knowing if a <code>\</code> signifies an escape character or a path separator. The output should probably be adjusted so a <code>\</code> is escaped to <code>\\</code>.</p> <p>Context: this fails for detecting tools.deps version as part of the integration into IntelliJ IDE with Cursive.</p> tools.deps.alpha Tue, 08 Jun 2021 09:20:01 +0000 Could tools.deps.alpha support :jvm-opts via aliases-as-data, the same as :paths/:extra-paths? <p>At work, we have four or five JVM options that are common to almost every invocation of the CLI via aliases in our <code>deps.edn</code> file. Currently, we have <code>:jvm-opts</code> duplicated into each alias.</p> <p>It would reduce duplication if we could just say <code>:jvm-opts :common-opts</code> in each alias and have a <code>:common-opts</code> alias that specified the JVM options in just one place or, even better, if the <code>:jvm-opts</code> vector could take a mix of keywords and strings and look up the keywords as aliases and merge that data in.</p> <p>This would make <code>:jvm-opts</code> consistent with <code>:paths</code> and <code>:extra-paths</code> and help reduce duplication in <code>deps.edn</code> files.</p> <p>In our specific case, we could then do the following:</p> <pre><code>;; under :aliases :common-jvm-opts ["-Dclojure.core.async.go-checking=true" "" "-XX:-OmitStackTraceInFastThrow" "--illegal-access=warn"]} ;; in a specific alias :some-alias { :jvm-opts [:common-jvm-opts "-Dlogged-future=synchronous"] } </code></pre> tools.deps.alpha Mon, 07 Jun 2021 18:37:03 +0000 Reflection warning when using tools.deps programatically <p>The following warning is a minor nuisance:</p> <pre><code>jar:file:/Users/vemv/.m2/repository/org/clojure/tools.deps.alpha/0.11.922/tools.deps.alpha-0.11.922.jar!/clojure/tools/deps/alpha/extensions/deps.clj:39:13: Reflection warning - reference to field getCanonicalPath can't be resolved. </code></pre> <p>could it be fixed?</p> <p>Thanks - V</p> tools.deps.alpha Sun, 06 Jun 2021 02:33:51 +0000 Does tools.deps.alpha need a maven-core bump? <p><code>tools.deps.alpha 0.11.918</code> uses <code>maven-core 3.6.3</code>, which seems to be affected by <a rel="nofollow" href="">CVE-2021-26291</a></p> <p>Does this present a risk for users of <code>tools.deps.alpha</code> or the Clojure command-line tools? Would it make sense to bump the referenced version?</p> tools.deps.alpha Thu, 20 May 2021 11:55:53 +0000 Specify an alias that is a set of other aliases? <p>It would be useful to have an alias that enables other aliases.</p> <p>One use case is sometimes doing development against just one project, but other times doing development against a collection of projects.</p> <p>Here's an example:</p> <pre><code>{:aliases {:dev/project1 {:override-deps {:local/root "/some/path/project1"}} :dev/project2 {:override-deps {:local/root "/some/path/project2"}} :dev/project3 {:override-deps {:local/root "/some/path/project3"}} ;; something like the following: :dev/all-projects {:aliases #{:dev/project1 :dev/project2 :dev/project3}}} </code></pre> tools.deps.alpha Mon, 03 May 2021 18:47:41 +0000 Using static files in project <p>Probably a very noob question, sorry about that. I have a monorepo structured like this:</p> <pre><code>api/ |-deps.edn |-src/ |-api/ |-core.clj |-resource_1.csv library/ |-deps.edn |-src/ |-library/ |-core.clj |-resource_2.csv </code></pre> <p>deps.edn of the api uses library as local dependency. Both of them use static information from respective csv files.</p> <p>My question is how do I correctly include the static files when compiling the api uberjar, and how do I correctly use the static files within the code?</p> <p>The api does not have any endpoints where it's serving the static files. They're used inside the code for caclulations.</p> IO Thu, 22 Apr 2021 18:13:10 +0000 Concurrency issues when launching multiple process with remote git coordinates <p>Hi, when launching multiple clojure processes with the same remote git coordinate, there seems to be concurrency issues when cloning the git repository.</p> <p>In this particular case, I was using node foreman to launch 2 or 3 different development workflows in parallel. One process would win and successfully clone the repo, while all others would fail with various errors. Once the git repo is successfully cloned, processes will run concurrently without issue.</p> <p>The workaround is to manually launch processes so that the git repo can be successfully cloned first. But not having to worry about the concurrency issues would be nice. I was wondering if this would be considered an issue, or if my expectations or usage are off.</p> <p>My clojure version is:</p> <pre><code>Clojure CLI version </code></pre> <p>My git version is:</p> <pre><code>git version 2.20.1 (Apple Git-117) </code></pre> <p>I have included two gists that contain log output of three different kinds of errors. The processes were run with the follow set:</p> <pre><code>export GITLIBS_DEBUG=true </code></pre> <ol> <li><a rel="nofollow" href=""></a></li> <li><a rel="nofollow" href=""></a></li> </ol> <p>Happy to provide more detail if it would help.</p> Clojure Wed, 21 Apr 2021 17:15:29 +0000 Support for shorthand commands in tools.deps <p>Based on feedback on Slack I would like to propose the support for shorthand commands in tools.deps.</p> <p>This would be something mirroring "aliases" in Leiningen and probably "scripts" in NPM. But not what is currently called "aliases" in tools.deps.<br> It should allow one to hide e.g.:<br> <code>clj -X:graph graph :deps '"mydeps.edn"' :trace true :output '"trace"</code> <br> behind<br> <code>clj graph</code></p> <p>Some examples of user facing commands with this in place:</p> <pre><code>clj start ; Similar to npm clj run ; Inspired by lein run clj backend ; Step 1 .. clj frontend ; Step 2 .. clj devcards ; Step 3 of firing up a fullstack project with some extras. </code></pre> <p>Exactly how it needs to work is something I'll leave to the implementors. If there has to be a reserved <code>run</code> or <code>start</code> making it e.g. <code>clj run backend</code> then that's the way it is, but the shorter the better. The term "shorthand command" is just I term i used to differentiate it from the already taken "aliases".</p> <p>Personally i believe this little bit of sugar would clean it up nicely in several ways and I'll try to capture that in the following.</p> <p>Some benefits of adding this:</p> <ul> <li>Aligns well with knowledge from using tools like Leiningen and NPM</li> <li>Everything in one deps.edn file.</li> <li>People and companies can have conventions that reuses the same shorthands across projects, making it dead simple to know how you fire up a project.</li> <li>Project documentation and guides could expose clean an concise commands.</li> </ul> <p>I know tools.deps is not intended to replace Leiningen, but it seems to have fragmented the already small Clojure(script) community and intended or not, my impression is that it’s used as a replacement as is, with no other tool wrapping it. Sure, you can still use lein, but enough people seem to have transitioned that it’s pretty much mandatory to know both. There is also Boot and maybe others, but I perceive that userbase as much smaller.</p> <p>I can cope and work around it, but whenever I write these long commands or document a project I feel that there has been some regression going on. Essentially I seem to work one abstraction level below of where I should be after the initial config of deps.edn is done.</p> <p>Some ways to approch tools.deps commands as it is today:</p> <ul> <li>Write by hand: Certainly possible, but requires more knowledge, experience, a good memory, depending on how involved the setup is and how similar your projects are.</li> <li>Copy paste from e.g. Works ok, but you have to refer to docs and it kind of makes Clojure look more complicated than it needs to.</li> <li>Shell scripts: Adds more files to a project and spreads the information more than if deps.edn was self contained.</li> <li>Shell command history: Easily accessible during a coding session or when working on the same for days, but less accessible weeks and months later.</li> <li>Other tooling wrapping it.</li> </ul> <p>So, I'm not arguing that the current situation is impossible to handle and Clojure seems to have an over the average tech savy userbase, but I think it could and should be cleaner. I can't really see how something clean and readable can hurt either. The current way of working feels a little bit elitistic as well, at least to me.</p> <p>While making this improvement won't change fragmentation, unless in the unlikely event that it completely takes over for Leiningen, it will at least align the two more. </p> <p>Extra functionality:<br> Maybe it should also support adding overrides after the shorthand (<code>clj backend -M:foo</code>), execute more than one shorthand in the same command (<code>clj backend frontend</code>) or similar, but that's something I don't have a strong opinion on right now.</p> <p>I hope these rather personal opinions explains well enough why this could be worthwhile.</p> <p>Lastly, imagine if, in the future, something like this was all the instructions you would have to give a Mac user to get started with some really nice fullstack work in Clojure(script):</p> <pre><code>brew install clojure clj new re-frame/app my-app cd my-app clj start </code></pre> <p>This request is not about adding some elegant template functionality to tools.deps as well, it's just an illustration of what a very streamlined experience could look like. Going from zero to the very productive experience of Clojure(script) development in so few step would be great. Not that you would be an expert straight away, but you could start editing files and see see e.g. hot code reloading just work.</p> Tools Sun, 04 Apr 2021 12:43:10 +0000 Should tools.namespace.repl/refresh exclude code found in ~/.gitlibs? <p>If you have a <code>deps.edn</code> project with a git dep in it, in a project where you're also using <code></code> then by default the <code>refresh</code> call will load and refresh all the clojure namespaces in your git dep.</p> <p>I think it does this because prior to tools.deps; essentially all library dependencies were distributed as jars, so it would assume that any directories in the classpath contain your projects source code, and would benefit from reloading via refresh.</p> <p>This assumption changes in <code>tools.deps</code> projects as deps can now be stored as files on the filesystem in the <code>~/.gitlibs</code> directory. These deps are essentially mistaken as project dependencies, and are all loaded and refreshed, even if your project does not actually <code>require</code> them. </p> <p>Given that <code>~/.gitlibs</code> are versioned and intended to be immutable, arguably it doesn't make sense to automatically require and refresh them.</p> <p>It is quite easily avoided by including a call to explicitly set your projects refresh-dirs with something like: <code>(tnsrepl/set-refresh-dirs "src" "test")</code>, however I wonder if it would be better for tools.namespace to exclude anything under <code>~/.gitlibs</code> by default, as tools.namespace's starting/default assumption no longer holds.</p> <p>NOTE this is also likely related <a rel="nofollow" href="">to this issue</a>.</p> tools.namespace Fri, 26 Mar 2021 14:43:59 +0000 clj -X:deps tree ignores -Sdeps <p>As the title says, <code>clj -X:deps tree</code> ignores the <code>-Sdeps</code> option:</p> <pre><code>$ clj -Sdeps '{:deps {ring/ring-core {:mvn/version "1.9.1"}}}' -X:deps tree org.clojure/clojure 1.10.2 . org.clojure/spec.alpha 0.2.194 . org.clojure/core.specs.alpha 0.2.56 </code></pre> <p>In contrast to <code>clj -Stree</code>:</p> <pre><code>$ clj -Sdeps '{:deps {ring/ring-core {:mvn/version "1.9.1"}}}' -Stree org.clojure/clojure 1.10.2 . org.clojure/spec.alpha 0.2.194 . org.clojure/core.specs.alpha 0.2.56 ring/ring-core 1.9.1 . ring/ring-codec 1.1.3 . commons-codec/commons-codec 1.15 . commons-io/commons-io 2.6 . commons-fileupload/commons-fileupload 1.4 X commons-io/commons-io 2.2 :older-version . crypto-random/crypto-random 1.2.0 X commons-codec/commons-codec 1.6 :older-version . crypto-equality/crypto-equality 1.0.0 </code></pre> <p>Is this behavior intended? If so, why?</p> <p>I believe it's intentional since I found this behavior comes from <a rel="nofollow" href="">this seemingly purposeful change,</a> but I still don’t get the reason for that.</p> <p>BTW I know there is a workaround like the following if I want to use <code>clj -X:deps tree</code> anyway:</p> <pre><code>$ clj -Sdeps ... -Strace $ clj -X:deps tree :file '"trace.edn"' </code></pre> tools.deps.alpha Fri, 26 Feb 2021 04:54:32 +0000 Issue loading cognitect test-runner dependency in deps.edn: USERAUTH fail. <p>I am trying to use the Cognitect test-runner dependency to run my tests and I am getting a jgit USERAUTH fail when it tries to clone the dependency. I can use other test runners but I really want to know what is going on here. Lots of other people have had this issue, but I haven't found a good explanation of the issue, nor a resolution. Would appreciate both if anyone can help!</p> <p>I'm using:</p> <p>Java 8 (tried 11 too)<br> Mac 10.15.7 (Catalina)</p> <p>I have a git ssh key without passcode</p> <p>Can someone explain to me what the issue is? I have an idea that it's to do with jgit/jsch but I don't fully understand what the problem is.</p> <p>my <code>deps.edn</code> :</p> <pre><code> {:paths ["src" "resources"] :deps {org.clojure/clojure {:mvn/version "1.10.2"}} :aliases { :test {:extra-paths ["test"] :extra-deps {com.cognitect/test-runner {:git/url "" :sha "209b64504cb3bd3b99ecfec7937b358a879f55c1"}} :main-opts ["-m" "cognitect.test-runner"]}} </code></pre> <p><code>clj -A:test</code> output:</p> <p> &gt; Cloning: <a rel="nofollow" href=""></a> Error</p> <pre><code>&gt; building classpath. &gt; USERAUTH fail org.eclipse.jgit.api.errors.TransportException: &gt; USERAUTH fail &gt; at &gt; at org.eclipse.jgit.api.CloneCommand.fetch( &gt; at &gt; at &gt; at$call_with_auth.invokeStatic(impl.clj:52) &gt; at$call_with_auth.invoke(impl.clj:43) &gt; at$git_clone_bare.invokeStatic(impl.clj:73) &gt; at$git_clone_bare.invoke(impl.clj:70) &gt; at$ensure_git_dir.invokeStatic(impl.clj:112) &gt; at$ensure_git_dir.invoke(impl.clj:102) &gt; at$resolve.invokeStatic(gitlibs.clj:33) &gt; at$resolve.invoke(gitlibs.clj:29) &gt; at$procure.invokeStatic(gitlibs.clj:47) &gt; at$procure.invoke(gitlibs.clj:41) &gt; at$eval1316$fn__1318.invoke(git.clj:42) &gt; at clojure.lang.MultiFn.invoke( &gt; at$expand_deps.invokeStatic(alpha.clj:422) &gt; at$expand_deps.invoke(alpha.clj:390) &gt; at$resolve_deps.invokeStatic(alpha.clj:495) &gt; at$resolve_deps.invoke(alpha.clj:475) &gt; at$calc_basis.invokeStatic(alpha.clj:648) &gt; at$calc_basis.invoke(alpha.clj:622) &gt; at$run_core.invokeStatic(make_classpath2.clj:91) &gt; at$run_core.invoke(make_classpath2.clj:57) &gt; at$run.invokeStatic(make_classpath2.clj:119) &gt; at$run.invoke(make_classpath2.clj:113) &gt; at$_main.invokeStatic(make_classpath2.clj:169) &gt; at$_main.doInvoke(make_classpath2.clj:140) &gt; at clojure.lang.RestFn.applyTo( &gt; at clojure.lang.Var.applyTo( &gt; at clojure.core$apply.invokeStatic(core.clj:667) &gt; at clojure.main$main_opt.invokeStatic(main.clj:514) &gt; at clojure.main$main_opt.invoke(main.clj:510) &gt; at clojure.main$main.invokeStatic(main.clj:664) &gt; at clojure.main$main.doInvoke(main.clj:616) &gt; at clojure.lang.RestFn.applyTo( &gt; at clojure.lang.Var.applyTo( &gt; at clojure.main.main( Caused by: org.eclipse.jgit.errors.TransportException: &gt; USERAUTH fail &gt; at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession( &gt; at org.eclipse.jgit.transport.SshTransport.getSession( &gt; at org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.&lt;init&gt;( &gt; at org.eclipse.jgit.transport.TransportGitSsh.openFetch( &gt; at org.eclipse.jgit.transport.FetchProcess.executeImp( &gt; at org.eclipse.jgit.transport.FetchProcess.execute( &gt; at org.eclipse.jgit.transport.Transport.fetch( &gt; at &gt; ... 37 more Caused by: com.jcraft.jsch.JSchException: USERAUTH fail &gt; at com.jcraft.jsch.UserAuthPublicKey.start( &gt; at com.jcraft.jsch.Session.connect( &gt; at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession( </code></pre> Clojure Wed, 24 Feb 2021 10:15:47 +0000 Add the CLI equivalent of Leiningen's sample.project.clj <p>Leiningen has an option to display a fully-populated, well-documented <code>project.clj</code> file (as the <code>sample.project.clj</code> file from its installation.</p> <p>The Clojure CLI has <code>example-deps.edn</code> which is laid down as <code>~/.clojure/deps.edn</code> on first use. It does have some examples but it doesn't have all the possible options shown -- in particular it doesn't show where <code>:jvm-opts</code> should live (a lot of people seem to expect it to work as a top-level key in <code>deps.edn</code> despite what the reference docs say about it being part of an alias.</p> <p>In addition, <code>example-deps.edn</code> still refers to <code>-R</code> and <code>-C</code> and doesn't mention <code>-X</code> or <code>-M</code>.</p> <p>It also, somewhat confusingly, repeats several aliases from the system <code>deps.edn</code> file as comments, suggesting that those are useful things to uncomment in a user <code>deps.edn</code> file.</p> Tools Tue, 26 Jan 2021 18:02:50 +0000 -X args: pass in entire map + merge strategy <p>I would like to pass in an entire arg map to <code>clojure -X</code> and decide using a custom function how this should be merged with the default one from deps.edn. This could be a function in the <code>:exec-fn</code> alias, e.g. <code>:exec-merge-args</code> (and could default to <code>merge</code> or something based on <code>merge-with</code>). </p> <p>My reason for this request is that passing in individual paths takes quite a lot of quoting on the command line for paths and strings. It would be less thinking and less error prone to just pass in one quoted map.</p> <p>This is related to <a rel="nofollow" href=""></a>.<br> If I could describe how this should be merged using a custom function, adding things to a vector would be sufficiently solved as well.</p> Clojure Fri, 15 Jan 2021 14:17:39 +0000 -X args: add things to vector <p>How does one update an arg map for <code>clojure -X</code> like in the following:</p> <p><code>{:some-tool {:scan-paths ["src"]}}</code></p> <p>Say I want to add <code>"test"</code> to this. How does one achieve this on the command line?</p> <p>Related: <a rel="nofollow" href=""></a></p> Clojure Fri, 15 Jan 2021 14:14:07 +0000 Could :replace-deps imply :replace-paths [] by default? <p>If an alias, or tool invocation using -Sdeps, discards a project's deps by using <code>:replace-deps</code> then there is a good chance that some or all of the project's namespaces become impossible to load due to their requirements now missing from the classpath.</p> <p>If there are files in the project's default paths that are auto-loaded by clojure on startup, such as <code>user.clj</code>, the tool invocation might fail therefore. This can be mitigated by also specifying <code>:replace-paths []</code>, however this does not seem to be too well known (<a rel="nofollow" href="">example 1</a>, <a rel="nofollow" href="">example 2</a>, <a rel="nofollow" href="">example 3</a>).</p> <p>I was wondering whether it is common for tools to replace a project's deps with their own but still use the project's paths? I believe in most cases the tool will be authored with no knowledge of the project it will be used in and should not expect to find anything useful to load from the project's own paths.</p> <p>In order to make it easier to set up tool invocations, it would make sense to me to make <code>:replace-deps</code> imply <code>:replace-paths []</code> unless otherwise specified, or something along these lines.</p> <p>A repro case can be found at <a rel="nofollow" href=""></a></p> <p>Migrated from <a rel="nofollow" href=""></a></p> <p>Edit: update opening paragraph to reference replace-deps as opposed to replace paths. I don't know why I wrote replace-paths there in the first place, this is about problems with replace-deps :)</p> tools.deps.alpha Tue, 15 Dec 2020 13:06:32 +0000 Could the CLI add an option that is a variant of -Sdeps to avoid having to specify an alias? <p>Currently, there are several parts of <code>deps.edn</code> that only work under an alias. That means that if you want to do that via the command-line, you have to do:</p> <pre><code>clojure -Sdeps '{:aliases {:foo {...}}}' -(AMX):foo ... </code></pre> <p>(for example, <code>:replace-deps</code> for tooling)</p> <p>It would be nice if you could just say:</p> <pre><code>clojure -Salias '{...}' -(AMX) ... </code></pre> <p>so you don't have to invent an alias, type that name twice, and wrap it in <code>{:aliases ...}</code>.</p> <p>Logged as <a rel="nofollow" href=""></a></p> tools.deps.alpha Tue, 24 Nov 2020 19:21:52 +0000 How can teams share common dependencies/tooling across multiple projects with deps.edn? <p>Here's my general problem statement (this applies to a monorepo as well):</p> <ol> <li>a development team works together on multiple projects that each have their <code>deps.edn</code> file, and </li> <li>those developers have their own preferred tooling configured in their own <code>~/.clojure/deps.edn</code> file, and </li> <li>the team as a whole wants a level of consistency in terms of certain library or tooling versions across multiple projects, by providing some standardized aliases and some "pinned" versions (e.g., <code>:override-deps</code> or <code>:default-deps</code>). </li> </ol> <p>Bullets 1. and 2. are supported by the CLI/t.d.a. but there's nowhere to hang the multi-project standardization piece.</p> <p>Currently, folks who want 3. are using <code>CLJ_CONFIG</code> to provide a team-standard <code>deps.edn</code> file but losing 1. in the process. This is considered a bit of a hack (although <code>CLJ_CONFIG</code> <em>is documented</em>).</p> <p>Michiel Borkent notes that his <code>clj-kondo</code> tool faced a similar problem in terms of where it reads configuration data from and his solution was to provide a command-line argument that specified multiple configuration files to read. A similar approach could be taken with the Clojure CLI, allowing an arbitrary number of <code>deps.edn</code> files to be combined (after the system + user level ones and before the command-line <code>-Sdeps</code> data).</p> <p>The current "system + user + project + command-line" logic is baked into <code>tools.deps.alpha</code> itself so this is not just a CLI script change -- and whatever approach is taken to address this needs to be available to tooling that needs to run analysis based on a combined <code>deps.edn</code> environment under user-specific aliases (as discussed here <a rel="nofollow" href=""></a>).</p> tools.deps.alpha Mon, 23 Nov 2020 20:34:46 +0000 How can tooling based on deps.edn/t.d.a construct a basis that is specified by aliases, without boilerplate code? <p>Discussion copied from Slack:</p> <p>It is fairly common for tooling to be want to read the <code>deps.edn</code> environment as if it were under a set of aliases, i.e., for a tool to want to see the world as if a specific set of aliases were provided, that are different to the aliases needed to run the tool. </p> <p>This touches on how <code>-X.. mvn-pom</code> works, as well as other tools on <a rel="nofollow" href=""></a> such as <code>depot</code>: the environment needed to run the tool is not the same as the environment the tool wants for analysis.</p> <p><code>depstar</code> "works around" this problem by relying on its own runtime environment being the same as what goes into the JAR file but just excluding itself. This is only tenable because it is a very small tool that has zero external dependencies. You can override this and tell <code>depstar</code> to use a different classpath, but that approach doesn't work for tools that actually want to look at the versions of dependencies, such as <code>mvn-pom</code>, <code>depot</code>, etc.</p> <p>Alex Miller said: "the datomic ion dev tools is another example"</p> <p>Michiel Borkent said: "I also have a couple of tools that just receive a <code>--classpath</code> arg. But it depends on the tool. For <code>mvn-pom</code> that might not be so convenient, and getting a list of aliases to resolve versions with might be better."</p> <p>Clarification of the "ask" here, and an addition courtesy of Alex: this process must take into account the various <code>deps.edn</code> files that the CLI already uses -- system, user, project, command-line -- and must respect the equivalent of <code>-Srepro</code> so that the user <code>deps.edn</code> can be elided if desired. In addition, if t.d.a is enhanced to support multiple "project" <code>deps.edn</code> files, per <a rel="nofollow" href=""></a>, then this process should also support that.</p> <p>What tools need is something in t.d.a that they can call with:</p> <ul> <li>A list of aliases</li> <li>An option equivalent to <code>-Srepro</code></li> <li>The implicit list of <code>deps.edn</code> files that match how the CLI would read them (this is intended to be weasel-wording to allow for the "extra <code>deps.edn</code> file" posited in that other "ask" to be specified here somehow</li> </ul> <p>The idea here is that tooling wants to mimic how the Clojure CLI processes <code>deps.edn</code> files and aliases and certain other options but the current API exposed by t.d.a is too low-level to make this easy and we don't want every tool based on t.d.a to have to duplicate all that multi-file merging and alias selection.</p> tools.deps.alpha Mon, 23 Nov 2020 20:19:27 +0000 clj -M: ignores :extra-paths in alias <p>Hi,</p> <p>it seems there is a bug with using clj -M:foo with :extra-paths in :aliases the classpath seems to not include the extra-paths</p> <p>deps.edn</p> <pre><code>{:aliases {:foo {:extra-paths ["dev"] :main-opts ["-m" "foo"]}}} </code></pre> <p>dev/foo.clj</p> <pre><code>(ns foo) (defn -main [&amp; args] (println "hello world")) </code></pre> <p>When running</p> <pre><code>clj -M:foo </code></pre> <p>We get</p> <blockquote><p>Execution error (FileNotFoundException) at clojure.main/main<br> ( Could not locate foo__init.class, foo.clj or foo.cljc<br> on classpath.</p> <p>Full report at: /tmp/clojure-8075946726191297006.edn</p> </blockquote> <p>Whereas</p> <pre><code>clj -A:foo -m foo </code></pre> <p>gives</p> <blockquote><p>hello world</p> </blockquote> <p>this difference is also visible via -Spath</p> <pre><code>clj -Spath -M:foo </code></pre> <blockquote><p>src:/home/mark/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar:/home/mark/.m2/repository/org/clojure/spec.alpha/0.2.176/spec.alpha-0.2.176.jar:/home/mark/.m2/repository/org/clojure/core.specs.alpha/0.2.44/core.specs.alpha-0.2.44.jar</p> </blockquote> <pre><code>clj -Spath -A:foo </code></pre> <blockquote><p>dev:src:/home/mark/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar:/home/mark/.m2/repository/org/clojure/spec.alpha/0.2.176/spec.alpha-0.2.176.jar:/home/mark/.m2/repository/org/clojure/core.specs.alpha/0.2.44/core.specs.alpha-0.2.44.jar</p> </blockquote> tools.deps.alpha Wed, 18 Nov 2020 00:49:01 +0000 Why is the clj mvn-pom task ignoring the -Srepro option? <p>I have a user-level deps.edn and a project-level deps.edn. I want to generate a pom.xml file for my project that ignores any dependencies in my user-level deps.edn. The command I have now is:</p> <pre><code>clj -Srepro -X:deps mvn-pom </code></pre> <p>According to the docs (and to the report provided by <code>-Sverbose</code>), this should ignore my user-level deps.edn. But I still see the dependencies from my user deps.edn appearing in the generated pom.xml! I've tried this with <code>-Sforce</code> also and nothing changed. Whether I use <code>-Spom</code> or <code>-X:deps mvn-pom</code>, it seems like the <code>-Srepro</code> option is ignored.</p> <p>Here's more info about my environment:</p> <pre><code>$ clj -Srepro -Sverbose -Sdescribe version = install_dir = /usr/local/Cellar/clojure/ config_dir = /Users/jming/.clojure config_paths = /usr/local/Cellar/clojure/ deps.edn cache_dir = .cpcache cp_file = .cpcache/1655984260.cp {:version "" :config-files ["/usr/local/Cellar/clojure/" "deps.edn" ] :config-user "" :config-project "deps.edn" :install-dir "/usr/local/Cellar/clojure/" :config-dir "/Users/jming/.clojure" :cache-dir ".cpcache" :force false :repro true :main-aliases "" :repl-aliases ""} </code></pre> <p>What am I doing wrong? Why does <code>-Srepro</code> appear to be doing nothing, despite what <code>-Sverbose</code> says? How can I keep user-level dev dependencies like <code>cljfmt</code> out of my pom.xml?</p> tools.deps.alpha Wed, 30 Sep 2020 00:47:30 +0000 Is it possible to override the paths of a git dep? <p>(I already asked this in Slack; I’m posting it here so it can be escalated into a JIRA issue, if the core team so desires.)</p> <p>There’s a library on GitHub that I’d like to use as a gitlib. However, I can’t right now, because its Clojure code is under <code>src/clj</code>, and there doesn’t seem to be a way to override the last segment of the path to the lib that gets added to the classpath.</p> <p>Is there a way to do this? If not, could a feature be added to support this?</p> <p>(BTW it might be helpful if there was a category for <code>tools</code> or <code>tools.deps</code> or <code>CLI tools</code>.)</p> tools.deps.alpha Wed, 20 May 2020 19:51:55 +0000 tools.deps.alpha add-lib branch throws PatternSyntaxException on Windows <p>The 'read-cp' function in fails when attempting to split the path-in-repo string value with a regex pattern of File/separator. This is on line 41.</p> <pre><code>(str/split path-in-repo (re-pattern File/separator)) </code></pre> <p>The File/separator evaluates to \\ on Windows, but for a regex pattern it needs to be \\\\</p> <p>This works fine on Linux and Mac OS</p> Clojure Mon, 30 Mar 2020 21:51:27 +0000 Is there a clojure cli equivalent to lein checkouts? <p><code>clj</code> allows us to specify local deps with the <code>:local/root</code> coordinate type, but when multiple developers share a <code>deps.edn</code> for a project, it is often the case that they have placed dependencies in different locations on their filesystems. <code>:local/root</code> allows relative paths, which helps with this a bit, but this doesn't allow the flexibility of lein checkouts, which are local file system symlinks that are not stored in version control. Does the clojure cli allow something like that?</p> Tools Fri, 13 Mar 2020 14:34:20 +0000 :scope in deps.edn should be added to and not deleted from pom.xml <p>There is an assumption that <code>tools.deps</code> will carry a <code>:scope "provided"</code> into the pom.xml when -Spom is run. However, not only is it not carried over, but if it already exists in the pom.xml then it is deleted... </p> <p>For example:</p> <pre><code>{:deps {com.datomic/datomic-free {:mvn/version "0.9.5697" :scope "provided"}}} </code></pre> <p>becomes:</p> <pre><code>&lt;dependency&gt; &lt;groupId&gt;com.datomic&lt;/groupId&gt; &lt;artifactId&gt;datomic-free&lt;/artifactId&gt; &lt;version&gt;0.9.5697&lt;/version&gt; &lt;/dependency&gt; </code></pre> <p>but should be:</p> <pre><code>&lt;dependency&gt; &lt;groupId&gt;com.datomic&lt;/groupId&gt; &lt;artifactId&gt;datomic-free&lt;/artifactId&gt; &lt;version&gt;0.9.5697&lt;/version&gt; &lt;scope&gt;provided&lt;/scope&gt; &lt;/dependency&gt; </code></pre> tools.deps.alpha Thu, 20 Feb 2020 21:29:41 +0000 clj -m works from shell but not as alias <p>Running the following at the command line:</p> <pre><code>clj -Acider -m "nrepl.cmdline" "--middleware" "[refactor-nrepl.middleware/wrap-refactor cider.nrepl/cider-middleware]" </code></pre> <p>Given:</p> <pre><code>:cider {:extra-deps {nrepl {:mvn/version "0.6.0"} refactor-nrepl {:mvn/version "2.5.0-SNAPSHOT"} cider/cider-nrepl {:mvn/version "0.23.0-SNAPSHOT"}}} </code></pre> <p>Works. But moving it to a :main-opts:</p> <pre><code>:cider {:extra-deps {nrepl {:mvn/version "0.6.0"} refactor-nrepl {:mvn/version "2.5.0-SNAPSHOT"} cider/cider-nrepl {:mvn/version "0.23.0-SNAPSHOT"}} :main-opts ["-m" "nrepl.cmdline" "--middleware" "[refactor-nrepl.middleware/wrap-refactor cider.nrepl/cider-middleware]"]} </code></pre> <p>And running:</p> <pre><code>clj -Acider </code></pre> <p>Fails with:</p> <pre><code>Exception in thread "main" java.lang.RuntimeException: EOF while reading [5/723] at clojure.lang.Util.runtimeException( at clojure.lang.EdnReader.readDelimitedList( at clojure.lang.EdnReader$VectorReader.invoke( at at at clojure.lang.EdnReader.readString( at clojure.edn$read_string.invokeStatic(edn.clj:46) at clojure.edn$read_string.invokeStatic(edn.clj:37) at clojure.edn$read_string.invoke(edn.clj:37) at nrepl.cmdline$parse_cli_values$fn__1275.invoke(cmdline.clj:248) at clojure.core$fn__8072$fn__8074.invoke(core.clj:6760) at clojure.core.protocols$iter_reduce.invokeStatic(protocols.clj:49) at clojure.core.protocols$fn__7839.invokeStatic(protocols.clj:75) at clojure.core.protocols$fn__7839.invoke(protocols.clj:75) at clojure.core.protocols$fn__7781$G__7776__7794.invoke(protocols.clj:13) at clojure.core$reduce.invokeStatic(core.clj:6748) at clojure.core$fn__8072.invokeStatic(core.clj:6750) at clojure.core$fn__8072.invoke(core.clj:6750) at clojure.core.protocols$fn__7860$G__7855__7869.invoke(protocols.clj:175) at clojure.core$reduce_kv.invokeStatic(core.clj:6776) at clojure.core$reduce_kv.invoke(core.clj:6767) at nrepl.cmdline$parse_cli_values.invokeStatic(cmdline.clj:246) at nrepl.cmdline$parse_cli_values.invoke(cmdline.clj:242) at nrepl.cmdline$args__GT_cli_options.invokeStatic(cmdline.clj:261) at nrepl.cmdline$args__GT_cli_options.invoke(cmdline.clj:253) at nrepl.cmdline$_main.invokeStatic(cmdline.clj:447) at nrepl.cmdline$_main.doInvoke(cmdline.clj:443) at clojure.lang.RestFn.applyTo( at clojure.lang.Var.applyTo( at clojure.core$apply.invokeStatic(core.clj:657) at clojure.main$main_opt.invokeStatic(main.clj:317) at clojure.main$main_opt.invoke(main.clj:313) at clojure.main$main.invokeStatic(main.clj:424) at clojure.main$main.doInvoke(main.clj:387) at clojure.lang.RestFn.applyTo( at clojure.lang.Var.applyTo( at clojure.main.main( </code></pre> tools.deps.alpha Wed, 15 Jan 2020 07:18:08 +0000 Using git deps in a restricted environment <p>As tools.deps gains traction, there are some libraries that are only available via git, eg <a rel="nofollow" href="">cognitect-labs/test-runner</a>. </p> <p>In some corporate environments without git (or general internet) access, where dependencies are acquired via tools like artifactory (for maven, npm etc), such libraries are troublesome to use. </p> <p>In such cases, what would your recommended approach be?</p> <ul> <li>find another library</li> <li>publish the library to maven either by yourself or asking the maintainers </li> <li>copy the source into your own source </li> <li>fork it into an internal (intranet) git repo and use that as a dependency</li> </ul> Tools Tue, 19 Nov 2019 09:19:20 +0000 Why is clojure not picking up installation level deps.edn? <p>I have a fresh install of clojure on a RHEL7 docker image, with the repos in /usr/local/lib/clojure/deps.edn (the installation level config) modified to point to our corporate artifactory repository. </p> <p>However, despite the -Sverbose option saying the file is in the config_paths, these repos are not picked up if running anywhere outside the directory itself. </p> <p>Doing something like <code>clojure -e “(clojure-version)”</code></p> <ul> <li>works from within the installation dir as the deps.edn is picked up as the ‘project’ config. This indicates there is nothing wrong with the config itself. </li> <li>fails in any other dir, saying it cannot connect to the default repos ( etc), which do not exist in any config file being checked. </li> </ul> <p>User level config is default (all commented) so should not impact, but -Srepro makes no difference. </p> <p>I can only conclude that the installation level config is not picked up correctly.</p> <p>Does anyone have any pointers here?</p> Tools Thu, 07 Nov 2019 04:01:55 +0000 Why does -A not merge deps across multiple aliases in tools.deps? <p>The <a rel="nofollow" href="">deps reference</a> says the -A option applies across all alias types. It also says if multiple -R alias maps are specified, they are merged. This to me implies that if only options available to -R are specified (like :extra-deps), then multiple -A maps will behave the same as multiple -R maps. </p> <p>Given the above, and two aliases with just :extra-deps specified, I expect the following to be equivalent:</p> <pre><code>clojure -R:a:b -Spath clojure -A:a:b -Spath </code></pre> <p>However, while -R generates a path with the deps of both :a and :b, the -A version only contains the deps of :b. </p> <p>Is this a bug or is the behaviour intentionally different? </p> <p>I tested this on the latest windows clojure</p> Tools Tue, 05 Nov 2019 03:38:08 +0000 tools.deps: Additional https repo not working <p>Migrating a leiningen project.clj to deps.edn has failed for the following:</p> <pre><code>{:deps {org.clojars.frozenlock/bacnet4j {:mvn/version "5.0.0-1" :exclusions [org.slf4j/slf4j-api lohbihler/sero-scheduler]} lohbihler/sero-scheduler {:mvn/version "1.1.0" :exclusions [org.slf4j/slf4j-api]}} :mvn/repos {"ias-releases" ""}} </code></pre> <p>This produces the following error:</p> <pre><code>Error building classpath. Failed to read artifact descriptor for lohbihler:sero-scheduler:jar:1.1.0 org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for lohbihler:sero-scheduler:jar:1.1.0 ... Caused by: org.eclipse.aether.transfer.NoTransporterException: Cannot access using the registered transporter factories: HttpTransporterFactory, FileTransporterFactory, WagonTransporterFactory </code></pre> <p>Am I missing something? I thought this approach was supposed to work. The leiningen project works just fine with <code>"ias-releases"</code> configured in <code>:repositories</code>.</p> tools.deps.alpha Fri, 13 Sep 2019 16:38:33 +0000