Clojure Q&A - Recent questions tagged dependencies

clojure-clr nrepl - .NET Standard 2.1. does not work with .NET 7

Mon, 22 May 2023 18:59:50 +0000

I've been encountering some issues when attempting to load libraries using clojure-clr in .NET 7 (core.async and clojure.tools.nrepl)

With the recent inclusion of NREPL, I was keen to explore its functionality. However, I'm met with an error when I try to require the namespace, stating:

"Could not locate clojure/tools/nrepl with extensions .cljr, .cljc, .cljr, .cljr.dll, .cljc.dll, or .clj.dll on load path."

It's interesting to note the distinction between the clojure-clr nrepl library and core.async, particularly in comparison to libraries like clojure.test.generative. The latter, for example, is compiled to .NET Standard 2.1 and functions correctly.

To aid in addressing this problem, I've created a repository which reproduces the nrepl bug. You can find it here: https://github.com/Dangercoder/clojure-clr-bug-report-1

I'm using dotnet tooling to manage dependencies.

Furthermore, I believe that resolving the issues with core.async is crucial since it would enable interoperability with https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.task?view=net-7.0. This feature is prevalent throughout the .NET environment.

Your assistance and input are much appreciated!

first build fails on ubuntu due to repo1.maven.org/maven2 timing out for orr.clojure artifact

Sun, 12 Mar 2023 08:48:39 +0000

clj command fails to build classpath on new installation!!!

Running a new installation of POP os, which is a late ubuntu derivative. I've run into this issue on my m1 mac as well. However, after removing the .m2 homedir the problem was solved. But on linux the issue persists.

using adopt temurin 17 jdk + jre

clj version: 1.11.1

all install steps followed from the docs were successful without issues. until you run clj or clojure from cli. The following trace is produced:

Error building classpath. Failed to read artifact descriptor for org.clojure:clojure:jar:1.11.1
org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.clojure:clojure:jar:1.11.1
	at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:255)
	at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:171)
	at org.eclipse.aether.internal.impl.DefaultRepositorySystem.readArtifactDescriptor(DefaultRepositorySystem.java:263)
	at clojure.tools.deps.extensions.maven$read_descriptor.invokeStatic(maven.clj:115)
	at clojure.tools.deps.extensions.maven$fn__1155.invokeStatic(maven.clj:143)
	at clojure.tools.deps.extensions.maven$fn__1155.invoke(maven.clj:143)
	at clojure.lang.MultiFn.invoke(MultiFn.java:244)
	at clojure.tools.deps$expand_deps$children_task__773$fn__775$fn__776.invoke(deps.clj:405)
	at clojure.tools.deps.util.concurrent$submit_task$task__481.invoke(concurrent.clj:35)
	at clojure.lang.AFn.call(AFn.java:18)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:833)

the lead error causing the above trace is the following:

Caused by: org.apache.http.conn.ConnectTimeoutException: Connect to repo1.maven.org:443 [repo1.maven.org/151.101.60.209] failed: Connect timed out

Running clj -Sforce after removing the .m2 dependencies yields the same result. Checking with other tools it seems that https://repo1.maven.org/maven2 is not reachable. I can't confirm if it is unreachable for others outside of my location. However the fact that removing and force-reinstalling deps on my mac worked tells me that something can be done to reoslve the issue. just not sure what.

Any help appreciated.

How to fix error 'could not acquire write lock for 'artifact:org.bytedeco:opencv:4.5.5-1.5.7' ?

Mon, 06 Mar 2023 14:25:23 +0000

depes.edn:

{:deps {org.deeplearning4j/deeplearning4j-nlp {:mvn/version "1.0.0-M2.1"}}}

It happened before in an older Clojure version, but disappeared, see here:

https://clojurians-log.clojureverse.org/tools-deps/2021-09-16

Now I have it back with a recent clojure CLI:
1.11.1.1200

The workarround is still to limit the number of download threads;

clj -Sthreads 1

So it only happens to me using (the default) multi-threaded downloading.

Add validation for lib groupId and name coordinate of git deps in tools.deps

Mon, 05 Sep 2022 02:56:53 +0000

In tools.deps, when using git deps, the following declared dependencies:

{io.github.xadecimal/riddley {...}}

{com.github.xadecimal/riddley {...}}

{com.xadecimal/riddley {:git/url "https://github.com/xadecimal/riddley.git" ...}}

{com.xadecimal/riddley {:mvn/version ...}}

{garbage/whatever {:git/url "https://github.com/xadecimal/riddley.git" ...}}

will all resolve, but they will not conflict against one another, even though they are all the same lib.

As it stands, the consumer that declares the dependency can choose from all these equivalent declarations, but if it chooses differently than any of its transitive dependencies have chosen, a hidden conflict is created, and more than one version of the lib will be pulled into the classpath, giving non-deterministic behavior to what version of the code will actually be used at runtime.

This problem could be solved by letting the lib author choose the canonical lib group/name that users must use always when declaring a dependency on it.

This can be achieved by adding a new key to deps.edn, such as :lib which takes a fully qualified symbol which will be validated against the symbol declared in the :deps map of the consuming libs.

deps.edn of the library being depended upon:

{:lib com.xadecimal/riddley ;; <-- This new key is added to deps.edn, declaring the canonical lib name
 :paths ["src"]
 :deps {...}
 ...}

deps.edn of the libraries that declare a dependency on the above lib:

{:paths ["src"]
 :deps {com.xadecimal/riddley {...}}
 ...}

When tools.deps resolves the above, it will check if the pulled lib has :lib key declared in its deps.edn, if it does, it will assert that the symbol used here matches the declared :lib symbol, if it does not, it will error to the user, making this an illegal dependency declaration. In the above it is correct, but in the following it is wrong:

deps.edn of a library that badly declared an illegal dependency on the above lib:

{:paths ["src"]
 :deps {com.github.xadecimal/riddley {...}}
 ...}

This would error, because even if the library is found at github.com/xadecimal/riddley.git and thus the above resolves, the library at github.com/xadecimal/riddley.git declared that its canonical lib name was com.xadecimal/riddley and not com.github.xadecimal/riddley. Therefore, in this case the only valid git dependency declaration is:

{:paths ["src"]
 :deps {com.xadecimal/riddley {:git/url "https://github.com/xadecimal/riddley.git" ...}}
 ...}

This validation would follow a similar ideology to asserting that the git/tag matches the git/sha, by asserting that the lib name used matches what the lib expects to uniquely be identified by.

Doing this allows conflict resolution to work as expected, and avoids the possibility that transitive dependencies use a different name, causing hidden runtime version conflicts not detected and resolved by tools.deps.

Will tools.build be released as a jar?

Wed, 05 Jan 2022 15:02:43 +0000

I am developing a library with a dependency on tools.build and I would like to publish it as a jar. Whilst tools.build is only available as a git dep, I cannot include it as a dependency in my pom file. A wider discussion on this topic was held on this slack thread, where @alexmiller requested that I raise this topic here.

tools.deps - How do I list dependencies and their versions from the REPL?

Thu, 11 Nov 2021 11:47:04 +0000

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?

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.

It's a tools.deps project

Problem whilst requiring clojure clojure.data.csv :as csv

Tue, 05 Jan 2021 21:25:07 +0000

I'm learning clojure trought the book "The Clojure Wokshop - Packt" and i have stucked for a few days in this exercise:

(My IDE is IntelliJ and i'm using Windows).

Exercise 4.10: Importing Data from a CSV File

1. Create a folder somewhere convenient on your computer.

I decided to create an entirely new project given how many attempts i tried.

Is there any difference here while choosing between Leiningen or Deps? I most of the time use Leiningen, but should i use Deps because i am gonna use a deps.edn file?

2. Download the match_scores_1991-2016_UNINDEXED.csv file to the folder you created. (here on github)

But where should i download this file? Into the src file inside the project file or any file works? Is there any difference?

I decided to save inside de src.

3. In your editor, in the same folder, create a deps.edn file with the following contents:

{:deps
 {org.clojure/data.csv {:mvn/version "0.1.4"}
  semantic-csv {:mvn/version "0.2.1-alpha1"}}}

So, i created a deps.edn file.

4. Verify that everything is working by evaluating the following expression in your REPL:

user> (require '[clojure.data.csv :as csv])
nil
user> (require '[clojure.java.io :as io])
nil
user> (with-open [r (io/reader "match_scores_1991-2016_unindexed_csv.csv")]
         (first (csv/read-csv r)))

When creating the REPL, should I select "Run with Intellij project classpath", right?

But when i am gonna evaluate the testing expressions, it shows an error while evaluating the second one and third one.

The error while evaluating the "clojure.data.csv :as csv" is this one:

Execution error (FileNotFoundException) at csv-example.core/eval1549 (form-init2604783929697477049.clj:1).
Could not locate clojure/data/csv__init.class, clojure/data/csv.clj or clojure/data/csv.cljc on classpath.

What am i missing? Have been trying for days to solve this but i didn't found any answer.

Thank you!

how to require clojure libs as classes instead of clj file to reduce repl start up time during development?

Sat, 03 Oct 2020 07:32:25 +0000

Hi!

i read about reducing repl start up time during dev and tried to apply these knowledge to start REPL using Leiningen (in the article Alex shows this practice using deps.edn).

My steps:

I overrided clojure.core/load var to track time elapsed on loading module with:

(alter-var-root #'clojure.core/load (fn [origin-fn]
                                  (if (get (meta origin-fn) ::track-load?)
                                    origin-fn
                                    (vary-meta (fn [& args]
                                                 (let [start# (System/nanoTime)
                                                       ret# (apply origin-fn args)
                                                       elapsed-ms# (/ (double (- (System/nanoTime) start#)) 1000000.0)]
                                                   (newline)
                                                   (pr {:args (vec args)
                                                        :ms   elapsed-ms#})
                                                   (newline)
                                                   ret#))
                                               merge
                                               {::track-load? true}))))

I noticed that loading core clojure parts takes time ~0.10-0.20 ms and loading third party libs modules (cheshire for example) , takes ~200-400ms.

As i understand, main idea of reducing REPL start up time is the priority of compiled class before clj module if clj module was not changed. So we can compile third party libs and get benefit of not parsing their clj files but use their compiled classes.

I compiled all clojure files (my and libs) via leiningen uberjar and added folder with compiled class files to :checkout-deps-shares, i guess it is a way to add folder with class files to classpath:

:checkout-deps-shares [:source-paths :test-paths
                     ~(fn [p] (str (:root p) "/target/uberjar/classes/*"))]

Then i restarted repl, overrided clojure.core/load to track modules load time and as experiment do following:

(time (require 'runtime.account :reload-all))

where runtime.account is one of my root modules.

As a result i cannot see any difference in loading time of third party libs modules :/.

Maybe you can give me some details about mechanism deciding to load class file or clj file and some way to monitor that activity?

Thanks!

Lein repl error: As of 2.8.2, the repl task is incompatible with Clojure versions older than 1.7.0.

Fri, 11 Sep 2020 23:06:45 +0000

I am trying to work through an example in the Clojure Workshop. I created a folder and in that included the following project.clj file.

(defproject learncsv "1.0.0-SNAPSHOT"
 :dependencies [[org.clojure/data.csv "1.0.0"]
             [semantic-csv "0.2.1-alpha1"]])

Then, I went to the terminal and typed

lein repl

I got the following error:

OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated 

in JDK 13 and will likely be removed in a future release.
As of 2.8.2, the repl task is incompatible with Clojure versions older than 1.7.0.
You can downgrade to 2.8.1 or use `lein trampoline run -m clojure.main` for a simpler 
 fallback repl.
Subprocess failed (exit code: 1)

I am super new to clojure. Never included any dependencies. Would really appreciate any help.

Edit: If I run lein repl in a folder that does not have any project.clj then it starts fine. And, it shows my clojure version as 1.10. So I am not sure why the error seems to suggest that I am using Clojure version older than 1.7.0

Thank you.

Compiling shadow-cljs projects with NPM transitive dependency conflicts

Thu, 26 Sep 2019 18:08:41 +0000

I am attempting to make use of the react-bootstrap module by leveraging NPM support in shadow-cljs.

First I add react-bootstrap and bootstrap to package.json:
$ yarn add react-bootstrap bootstrap

And then require react-bootstrap in my project:
(ns myproject.core (:require ["react-bootstrap" :as bs]))

The result is a runtime exception in the console:
TypeError: (0 , _uncontrollable.default) is not a function
... which curiously goes away after the first hot-reload.

The exception likely indicates a conflict in a nested NPM dependency. How can I identity and resolve the problem?