Clojurians Log v2

@alexmiller I’m running into a number of cases where I want to build a library (and publish it to a maven repository) that relies on a library that only provides a gitdep. Libraries or projects using this published library then dont have access to the gitdep since its not representable in the pom. Is there a recommended way to deal with this? Or is the advice to publish copies of these git libraries to maven ourselves?

that's the only path afaik

I mean, you can ask the owner to do so of course

if you have questions about how to best do so, you can ask at #clojars

Thanks. Do you think its worth publishing a note about this case in the docs? I didn’t make the logical leap about the effects of designing against gitdeps. Im sure others will likely not either. https://github.com/juxt/pack.alpha/issues/91

Ran into this again today with https://github.com/roman01la/uix

Even though I’d posted an issue about this exact case in. November, I forgot about it and ran into the same thing

I’m concerned we end up with a bunch of library authors not realising the results of not publishing to Clojars or something similar

The idea of pulling deps.edn from jars was floated as a solution for this at some point.

Currently I’m forking libs, and publishing to an internal maven repo. But from a maintenance POV this is quite an ask, especially for folks who don’t necessarily have access to the same infrastructure setup we do. Also considering dep resolution will no longer work, I’m thinking a better way of dealing with this might make sense to consider.

Is there a way to use tools.deps to know which SNAPSHOT version is currently resolved. For example <https://repo.clojars.org/kitchen-async/kitchen-async/0.1.0-SNAPSHOT/kitchen-async-0.1.0-SNAPSHOT.jar> currently becomes <https://repo.clojars.org/kitchen-async/kitchen-async/0.1.0-SNAPSHOT/kitchen-async-0.1.0-20191108.004735-9.jar> but I don't seem to be able to retrieve 20191108.004735-9 from the functions I've tested in clojure.tools.deps.alpha.extensions, but I didn't test everything. That first url is made up, but I pass kitchen-async/kitchen-async #:mvn{:version "0.1.0-SNAPSHOT"} {"central" {:url "<https://repo1.maven.org/maven2/>"}, "clojars" {:url "<https://repo.clojars.org/>"}} as parameters (depending on the function I'm testing).

I don't believe tools.deps does anything with SNAPSHOT, it just gets passed on to the maven code, which picks a version when it actually looks at what is in the repos

ok, so I should rather point my attention to aether for this?

From tools.deps - no. From aether, I’m not really sure how to do it there either

You request the snapshot version and it resolves that to a url but I don’t think you can see the time stamped version

I guess my question would be why do you care?

It's for a simple app I made in nix, where I create a file with all the endpoints and the artifact's hashsum. Appearently some other people are using it, and a user made a ticket that snapshot versions are returning 404.

Snapshot is very against integrity, but if the artifact is timestamped, it can be "frozen" to the time which the endpoints are generated.

well, the Maven solution to that is a non-SNAPSHOT release

that sort of compounds the error of using snapshots, different people running the tool will resolve the snapshot differently

so its frozen, but no one agrees to what it is frozen as

you can directly depend on the timestamped version too

@hiredman true that, the generated nix file will be frozen but not the file that generated it. It would be convenience that it would work. I think any serious release should be adviced against using snapshot versions in general.

I will try other options, thanks for both of your inputs.

Hello! I am using a mac mini with an M1 chip and it seems I can’t add a private github repo in my deps.edn file. The JDK I am using is this:

openjdk 11.0.9.1 2020-11-04 LTS
OpenJDK Runtime Environment Zulu11.43+1015-CA (build 11.0.9.1+1-LTS)
OpenJDK 64-Bit Server VM Zulu11.43+1015-CA (build 11.0.9.1+1-LTS, mixed mode)

Error building classpath. /private/var/folders/kv/64_g981979325dj8jwwd90fc0000gn/T/jna-106985/jna3259090784966322613.tmp: dlopen(/private/var/folders/kv/64_g981979325dj8jwwd90fc0000gn/T/jna-106985/jna3259090784966322613.tmp, 1): no suitable image found.  Did find:
[watch:cljs] 	/private/var/folders/kv/64_g981979325dj8jwwd90fc0000gn/T/jna-106985/jna3259090784966322613.tmp: no matching architecture in universal wrapper
[watch:cljs] 	/private/var/folders/kv/64_g981979325dj8jwwd90fc0000gn/T/jna-106985/jna3259090784966322613.tmp: no matching architecture in universal wrapper
[watch:cljs] java.lang.UnsatisfiedLinkError: /private/var/folders/kv/64_g981979325dj8jwwd90fc0000gn/T/jna-106985/jna3259090784966322613.tmp: dlopen(/private/var/folders/kv/64_g981979325dj8jwwd90fc0000gn/T/jna-106985/jna3259090784966322613.tmp, 1): no suitable image found.  Did find:
[watch:cljs] 	/private/var/folders/kv/64_g981979325dj8jwwd90fc0000gn/T/jna-106985/jna3259090784966322613.tmp: no matching architecture in universal wrapper
[watch:cljs] 	/private/var/folders/kv/64_g981979325dj8jwwd90fc0000gn/T/jna-106985/jna3259090784966322613.tmp: no matching architecture in universal wrapper
[watch:cljs] 	at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
[watch:cljs] 	at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2442)
[watch:cljs] 	at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2498)
[watch:cljs] 	at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2694)
[watch:cljs] 	at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2627)
[watch:cljs] 	at java.base/java.lang.Runtime.load0(Runtime.java:768)
[watch:cljs] 	at java.base/java.lang.System.load(System.java:1837)
[watch:cljs] 	at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:761)
[watch:cljs] 	at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:736)
[watch:cljs] 	at com.sun.jna.Native.<clinit>(Native.java:131)
[watch:cljs] 	at com.jcraft.jsch.agentproxy.usocket.JNAUSocketFactory$CLibrary.<clinit>(JNAUSocketFactory.java:47)
[watch:cljs] 	at com.jcraft.jsch.agentproxy.usocket.JNAUSocketFactory.open(JNAUSocketFactory.java:114)
[watch:cljs] 	at com.jcraft.jsch.agentproxy.connector.SSHAgentConnector.open(SSHAgentConnector.java:93)
[watch:cljs] 	at com.jcraft.jsch.agentproxy.connector.SSHAgentConnector.<init>(SSHAgentConnector.java:54)
[watch:cljs] 	at com.jcraft.jsch.agentproxy.ConnectorFactory.createConnector(ConnectorFactory.java:104)
[watch:cljs] 	at clojure.tools.gitlibs.impl$fn__1250.invokeStatic(impl.clj:31)
[watch:cljs] 	at clojure.tools.gitlibs.impl$fn__1250.invoke(impl.clj:29)
[watch:cljs] 	at clojure.lang.Delay.deref(Delay.java:42)
[watch:cljs] 	at clojure.core$deref.invokeStatic(core.clj:2320)
[watch:cljs] 	at clojure.core$deref.invoke(core.clj:2306)
[watch:cljs] 	at clojure.tools.gitlibs.impl$call_with_auth.invokeStatic(impl.clj:51)
[watch:cljs] 	at clojure.tools.gitlibs.impl$call_with_auth.invoke(impl.clj:43)
[watch:cljs] 	at clojure.tools.gitlibs.impl$git_clone_bare.invokeStatic(impl.clj:73)
[watch:cljs] 	at clojure.tools.gitlibs.impl$git_clone_bare.invoke(impl.clj:70)
[watch:cljs] 	at clojure.tools.gitlibs.impl$ensure_git_dir.invokeStatic(impl.clj:112)
[watch:cljs] 	at clojure.tools.gitlibs.impl$ensure_git_dir.invoke(impl.clj:102)
[watch:cljs] 	at clojure.tools.gitlibs$resolve.invokeStatic(gitlibs.clj:33)
[watch:cljs] 	at clojure.tools.gitlibs$resolve.invoke(gitlibs.clj:29)
[watch:cljs] 	at clojure.tools.gitlibs$procure.invokeStatic(gitlibs.clj:47)
[watch:cljs] 	at clojure.tools.gitlibs$procure.invoke(gitlibs.clj:41)
[watch:cljs] 	at clojure.tools.deps.alpha.extensions.git$eval1316$fn__1318.invoke(git.clj:42)
[watch:cljs] 	at clojure.lang.MultiFn.invoke(MultiFn.java:239)
[watch:cljs] 	at clojure.tools.deps.alpha$expand_deps.invokeStatic(alpha.clj:422)
[watch:cljs] 	at clojure.tools.deps.alpha$expand_deps.invoke(alpha.clj:390)
[watch:cljs] 	at clojure.tools.deps.alpha$resolve_deps.invokeStatic(alpha.clj:495)
[watch:cljs] 	at clojure.tools.deps.alpha$resolve_deps.invoke(alpha.clj:475)
[watch:cljs] 	at clojure.tools.deps.alpha$calc_basis.invokeStatic(alpha.clj:648)
[watch:cljs] 	at clojure.tools.deps.alpha$calc_basis.invoke(alpha.clj:622)
[watch:cljs] 	at clojure.tools.deps.alpha.script.make_classpath2$run_core.invokeStatic(make_classpath2.clj:91)
[watch:cljs] 	at clojure.tools.deps.alpha.script.make_classpath2$run_core.invoke(make_classpath2.clj:57)
[watch:cljs] 	at clojure.tools.deps.alpha.script.make_classpath2$run.invokeStatic(make_classpath2.clj:119)
[watch:cljs] 	at clojure.tools.deps.alpha.script.make_classpath2$run.invoke(make_classpath2.clj:113)
[watch:cljs] 	at clojure.tools.deps.alpha.script.make_classpath2$_main.invokeStatic(make_classpath2.clj:169)
[watch:cljs] 	at clojure.tools.deps.alpha.script.make_classpath2$_main.doInvoke(make_classpath2.clj:140)
[watch:cljs] 	at clojure.lang.RestFn.applyTo(RestFn.java:137)
[watch:cljs] 	at clojure.lang.Var.applyTo(Var.java:705)
[watch:cljs] 	at clojure.core$apply.invokeStatic(core.clj:665)
[watch:cljs] 	at clojure.main$main_opt.invokeStatic(main.clj:514)
[watch:cljs] 	at clojure.main$main_opt.invoke(main.clj:510)
[watch:cljs] 	at clojure.main$main.invokeStatic(main.clj:664)
[watch:cljs] 	at clojure.main$main.doInvoke(main.clj:616)
[watch:cljs] 	at clojure.lang.RestFn.applyTo(RestFn.java:137)
[watch:cljs] 	at clojure.lang.Var.applyTo(Var.java:705)
[watch:cljs] 	at clojure.main.main(main.java:40)

you are doing something that selects a classifier dep based on architecture

for a dep that has native stuff in it

@alexmiller make-classpath I think is triggering this? Looks like jsch to me?

so probably jgit?

oh yeah, it's tools.deps itself

but yes, jsch for ssh git support

So, no ARM support for (that version) of jsch?

probably not anything easy to fix at the drop of a hat

can you avoid using a git dep?

(or more likely JCE directly in the JDK doesn't support ARM?)

or use an https git dep? that should work as the ssh code is in a delay that won't be forced

Thanks for the prompt responses 🙂 Yes, I can just have the repo live in the project and use :local/root

@lucio Is that JDK specifically for the ARM chip or are you relying on Rosetta emulation?

That’s specific for the ARM chip.. I haven’t tried yet an emulated one tbh

'k... hmm, I would have expected JCE to work then. Good job you have a workaround with a local dep.

Out of curiosity I’ll give it a spin with an emulated jdk

seems like jna not quite there yet https://github.com/java-native-access/jna/pull/1238

@alexmiller When you say to try https you mean:

bar {:git/url "<https://github.com/foo/bar>"
     :sha "..."}

but that’s fine anyways.. I’ll simply get it in the repo for now 🙂 Thanks all again

yes, that's what I meant