Clojurians Log v2

What does this mean?

Exception in thread "main" clojure.lang.ExceptionInfo: Manifest type not detected when finding deps for babashka.curl/babashka.curl in coordinate {:git/url "<https://github.com/borkdude/babashka.curl>", :sha "2dc7f53271de3c2edc3e1474a000b9dfa7324eaf"} {:lib babashka.curl/babashka.curl, :coord {:git/url "<https://github.com/borkdude/babashka.curl>", :sha "2dc7f53271de3c2edc3e1474a000b9dfa7324eaf"}}, compiling:(/tmp/prog.clj:3:1)

as a result of:

(require '[clojure.tools.deps.alpha :as deps])

(-> {:deps '{babashka.curl
             {:git/url "<https://github.com/borkdude/babashka.curl>"
              :sha "2dc7f53271de3c2edc3e1474a000b9dfa7324eaf"}}
     :mvn/repos {"central" {:url "<https://repo1.maven.org/maven2/>"}
                 "clojars" {:url "<https://repo.clojars.org/>"}}}
    (deps/resolve-deps nil)
    (deps/make-classpath nil nil))

I get the same result when using this coordinate with -Sdeps from the command line

due to empty :deps? https://github.com/borkdude/babashka.curl/blob/2dc7f53271de3c2edc3e1474a000b9dfa7324eaf/deps.edn#L1

That appears to be it. Weird.

Thanks!

You are most welcome, by chance I hit that one yesterday.

https://clojure.atlassian.net/browse/TDEPS-156

@lee Hmm, now it's coming back:

$ clj -Sdeps "{:deps {babashka.curl
              {:git/url \"<https://github.com/borkdude/babashka.curl>\"
               :sha \"cbf8429addac1d2f71ac8ddfb847657223fdf0f7\"}}}" -Spath
Error building classpath. Manifest type not detected when finding deps for babashka.curl/babashka.curl in coordinate {:git/url "<https://github.com/borkdude/babashka.curl>", :sha "cbf8429addac1d2f71ac8ddfb847657223fdf0f7"}

it did work for:

$ clj -Sdeps "{:deps {babashka.curl
              {:git/url \"<https://github.com/borkdude/babashka.curl>\"
               :sha \"1dc0f61d7baabee1f009543d60bfb79ee4a7101c\"}}}" -Spath

while the commit cbf8 didn't do anything relevant compared to 1dc0with the deps.edn file....

Adding :deps/manifest :deps seems to fix it.

Added this to the issue

I'm also getting this for a local/root dep:

$ clj -Sdeps "{:deps {org.clojure/tda {:local/root \"/Users/borkdude/Dropbox/dev/temp/tools.deps.alpha\" }}}" -Spath
Error building classpath. Manifest type not detected when finding deps for org.clojure/tda in coordinate #:local{:root "/Users/borkdude/Dropbox/dev/temp/tools.deps.alpha"}

Are they reproducible with -Sforce

same result

/tmp $ clj -Sdeps "{:deps {babashka.curl
              {:git/url \"<https://github.com/borkdude/babashka.curl>\"
               :sha \"cbf8429addac1d2f71ac8ddfb847657223fdf0f7\"}}}" -Spath -Sforce -Srepro
Error building classpath. Manifest type not detected when finding deps for babashka.curl/babashka.curl in coordinate {:git/url "<https://github.com/borkdude/babashka.curl>", :sha "cbf8429addac1d2f71ac8ddfb847657223fdf0f7"}

@borkdude I can't repro any of your failing cases

Hah. Worked after a rm -rf ~/.gitlibs

Not for

clj -Sdeps "{:deps {org.clojure/tda {:local/root \"/Users/borkdude/Dropbox/dev/temp/tools.deps.alpha\" }}}" -Spath

That's probably another problem. It does work with a vanilla checkout of tools.deps:

clj -Sdeps "{:deps {org.clojure/tda {:local/root \"tools.deps.alpha\" }}}" -Spath

I'll close the issue.

this should not affect anything

do you have a repro of that?

tools.deps.alpha has a couple build steps (java compilation, resource replacement) so it's not a good example lib for use as local/git dep

btw, in the near future, using unqualified lib symbols is going to be deprecated and will complain, so "babashka.curl" should be changed to "babashka.curl/babashka.curl" etc

(and this is a step towards actually removing support for that)

@alexmiller I know. I had already compiled the java and added target/classes to the paths

But still didn’t work probably due to the resource replacement

I’m trying to get the native tools deps working using Ghadi’s git shell branch of the git libs library, but this stuff got me distracted for now

Should probably push the compiled assets to Clojars and work with that instead of tools deps deps

Btw, the url of a git dep is already a unique identifier. Why should a user have to make up some fully symbol keyword in the first place?

well you can just mvn clean install and use that local snapshot artifact too - sometimes that's eaesiest for maven built things

oh, looks like I misdiagnosed! thanks for the info!

re unique id, for the exact same reasons namespaces are useful for global differentiation, group-ids are a good idea for qualified names. using same symbol group+artifact was always a limited idea. lein/clojars made it too easy and common. we're not going to perpetuate making it implicit.

it's just map merges and stuff in the code, so I would not expect it to violate any Clojure-ish expectations here

But why have a name for a git dep at all?

because names are the identity of the lib, which may exist at different coordinates and you want to avoid putting the "same" lib on the classpath from multiple locations

(admittedly still some work to do on cross-coordinate type version selection, but the hooks are there)

Good point. The only use case for doing that would be when you would mount different dirs from the same git dep at different SHAs, which seems far fetched. Still if you would use the URL as the identifier you would be able to detect conflicts more easily since different people are going to use different qualified syms for the same lib?

we do not currently do that level of detection but it is something I would like to do

ultimately the library has to determine the identifier by which it should be known

the organization should be something you own or register, like domain name, trademark. third party sites like github can also confer identity - we recommend in https://clojure.org/guides/deps_and_cli to combine them by creating a group-id like github-borkdude

Which the URL is already an instance of

url is really a combination of site (github), org, and repo. github-org/repo combines those

but it does not account for forks

Interesting :thinking_face:

to use a fork, you need to use the same lib, but different url, and then they diverge

your goal with using a fork really is to replace (identity) the lib

but then you have interesting questions of ownership over the lib identity

If I want to maintain a fork as a real fork, and not just for PRs, I would not use the original identifier anyway?

well that's the question

So then the URL still is the most identifying thing for it

if you didn't use the original, then dep resolution will give you both libs if you have a transitive dep using the original

and in that case, it would be good to have deps tell you that you've done this

It’s the same in maven world right now

true

although probably much harder to automatically detect

(note that git urls are also not unique - there are multiple url formats to refer to the same repo, but I think that's a solvable problem)

I have got something compiling now with tda + tools.gitlibs@shell-git branch One issue I stumbled upon:

Error: com.oracle.graal.pointsto.constraints.UnresolvedElementException: Discovered unresolved type during parsing: org.apache.maven.project.ReactorModelPool. To diagnose the issue you can use the --allow-incomplete-classpath option. The missing type is then reported at run time when it is accessed the first time.
Detailed message:
Trace:
	at parsing clojure.tools.deps.alpha.extensions.pom$model_resolver.invokeStatic(pom.clj:51)
Call path from entry point to clojure.tools.deps.alpha.extensions.pom$model_resolver.invokeStatic(Object):
	at clojure.tools.deps.alpha.extensions.pom$model_resolver.invokeStatic(pom.clj:41)
	at clojure.tools.deps.alpha.extensions.pom$model_resolver.invoke(pom.clj:41)
	at clojure.core.proxy$clojure.lang.APersistentMap$ff19274a.hashCode(Unknown Source)
	at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936)
	at java.util.Properties.getProperty(Properties.java:1125)
	at com.oracle.svm.core.jdk.SystemPropertiesSupport.getProperty(SystemPropertiesSupport.java:144)
	at com.oracle.svm.core.jdk.Target_java_lang_System.getProperty(JavaLangSubstitutions.java:345)
	at com.oracle.svm.jni.JNIJavaCallWrappers.jniInvoke_VA_LIST:Ljava_lang_System_2_0002egetProperty_00028Ljava_lang_String_2_00029Ljava_lang_String_2(generated:0)

It is almost certainly related

There is a similar thing like this logged where an error occurs while setting up the service locator

So ditching jgit for shell git works. When are you going to ditch org.apache.maven libs? 😉

I wonder what's the issue with this class

Posted current findings + code here: https://github.com/borkdude/tools-deps-native-experiment

before using a solution like shelling out to git, I think it’s wise to re-examine the problem

I know I sound like a broken record

Alex pointed me at that shell-git branch when I told him jgit didn't work with GraalVM. Just examining + listing all the problems. Shelling out to git allows me to explore the next problem without being stuck on it. There might not be only one "the problem", there might be many.

what part of jgit didn't work?

I think the output I got was similar to this one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=546175

I think that problem should be solvable using the approach quarkus takes: https://quarkus.io/guides/jgit

so if there's need, it can be made to work, I'm pretty sure

I added this as a note to the README here now https://github.com/borkdude/tools-deps-native-experiment/blob/master/README.md