Fork me on GitHub
#tools-deps
<
2020-12-15
>
Alexis Vincent14:12:42

@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?

alexmiller14:12:40

that's the only path afaik

alexmiller14:12:02

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

alexmiller14:12:23

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

Alexis Vincent14:12:27

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

Alexis Vincent14:12:22

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

Alexis Vincent14:12:30

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

dominicm15:12:50

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

Alexis Vincent15:12:15

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.

hlolli18:12:04

Is there a way to use tools.deps to know which SNAPSHOT version is currently resolved. For example currently becomes 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 ""}, "clojars" {:url ""}} as parameters (depending on the function I'm testing).

hiredman18:12:48

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

hlolli18:12:12

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

alexmiller18:12:56

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

alexmiller18:12:34

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

alexmiller18:12:02

I guess my question would be why do you care?

hlolli18:12:41

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.

hlolli18:12:25

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

alexmiller18:12:00

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

hiredman18:12:13

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

hiredman18:12:35

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

hiredman18:12:03

you can directly depend on the timestamped version too

hlolli18:12:33

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

hlolli18:12:17

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

Lu22:12:25

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)
and you can find the error in the thread (not to pollute the main chat) 🙂.

Lu22:12:48

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)

alexmiller22:12:37

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

alexmiller22:12:57

for a dep that has native stuff in it

dominicm22:12:08

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

dominicm22:12:10

so probably jgit?

alexmiller22:12:25

oh yeah, it's tools.deps itself

alexmiller22:12:34

but yes, jsch for ssh git support

seancorfield22:12:24

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

alexmiller22:12:34

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

alexmiller22:12:21

can you avoid using a git dep?

seancorfield22:12:00

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

alexmiller22:12:48

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

Lu22:12:00

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

seancorfield22:12:06

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

Lu22:12:27

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

seancorfield22:12:59

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

👍 3
Lu22:12:53

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

Lu22:12:01

@alexmiller When you say to try https you mean:

bar {:git/url ""
     :sha "..."}
This is failing due to authentication - no CredentialsProvider has been registered

Lu22:12:18

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

alexmiller22:12:36

yes, that's what I meant

🙏 3