Can someone explain how do I build a classpath properly?

(deps/make-classpath
  (deps/resolve-deps {:deps {'re-find {:git/url ""
                                       :sha "c27af619a9d9e12832b7446e127d68ab916ce78c"}}}
                     nil)
  nil 
  nil)

Apparently I had to add :paths ["src"] to map, which works, but feels a bit wrong... shouldn't it be the default? if I'll set :paths to ["src/clj"] in my ~/.clojure/deps.edn, will it break dependencies because I overridden their source path?

Apparently I had to add :paths ["src"] to map, which works, but feels a bit wrong... shouldn't it be the default? if I'll set :paths to ["src/clj"] in my ~/.clojure/deps.edn, will it break dependencies because I overridden their source path?

:paths ["src"] is in the install-level deps.edn, but when you're using the library directly, you're in full control of what you include

setting to "src/clj" only affects your lib, not transitive deps - they set their own paths in their own deps.edn

that's the thing, re-find does not set :paths explicitly, that's why I need to specify ["src"]

it all works until everyone's system :paths property is the same

setting "src/clj" affects dependent libs too

(run! println 
      (str/split 
        (deps/make-classpath
          (deps/resolve-deps
            {:deps {'re-find {:git/url ""
                              :sha "c27af619a9d9e12832b7446e127d68ab916ce78c"}}
             :paths ["src/clj"]}
            nil)
          nil
          nil)
        #":"))
=> 
/home/vlaaad/.gitlibs/libs/re-find/re-find/c27af619a9d9e12832b7446e127d68ab916ce78c/src/clj
/home/vlaaad/.m2/repository/org/clojure/tools.cli/0.4.1/tools.cli-0.4.1.jar
/home/vlaaad/.m2/repository/org/clojure/math.combinatorics/0.1.4/math.combinatorics-0.1.4.jar
/home/vlaaad/.m2/repository/org/clojure/clojure/1.8.0/clojure-1.8.0.jar

re-find sources are implicitly on src, not src/clj, but it gets overridden

sorry, I don't understand what you're saying

it looks like answer above is what I would expect to see

it looks like answer above is what I would expect to see

I am surprised that I have to specify :paths to get code from git dependency

I expect gitlibs to have default :paths ["src"]

oh, I see what you're saying

it's up to libs to specify their own paths and re-find could (probably should) set :paths ["src"], and if it did, that would be used

you're seeing src/clj there due to a bug, where if no paths are used, the paths in the root deps.edn are used

https://clojure.atlassian.net/projects/TDEPS/issues/TDEPS-96 (may be other tickets that cover this too)

https://clojure.atlassian.net/projects/TDEPS/issues/TDEPS-52 is same thing

ah, it's already reported, nice

yeah, the cause is bound up in some other issues so I've had a long mull about how to fix, but ready to move forward on it when I have some time

clojure.tools.deps.alpha.specs seem wrong

(s/def :local/root string?)
(s/def :local/coord (s/keys :req-un [:local/root] :opt-un [::path]))

shouldn't it be :req instead of :req-un?

yes, I think you're right

fixed

I'm attempting to build an uberjar using deps + uberdeps Everything works as expected until i try to run the uberjar and it tells me it cant find clojure.main.

➜  cat deps.edn 

{:aliases {
            :uberjar {:extra-deps {uberdeps {:mvn/version "0.1.4"}}
                      :main-opts ["-m" "uberdeps.uberjar"]}}}
➜   clj -A:uberjar
[uberdeps] Packaging target/frog.jar...
[uberdeps] Packaged target/frog.jar in 2 ms
➜   cat src/core.clj 
(ns frog.core
  (:gen-class))

(defn -main [& args]
  (println "HIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII"))
➜   java -cp target/frog.jar clojure.main -m frog.core                 

Error: Could not find or load main class clojure.main
Caused by: java.lang.ClassNotFoundException: clojure.main

if you don't have clojure in your deps

some of it depends on how smart the uberdeps library is

if you don't include a dep on clojure explicitly, you will fallback to whatever is in the system (or whatever it is called) deps.edn file that was installed when you installed clj

but uberdeps might not be processing your deps.edn file using the tools.deps code, so it might not know to do that fallback

so if you don't get include a clojure version in your deps.edn, there wouldn't be clojure in your jar

yep

it just slurps in the edn and reads it

a lot of tools built on top of deps.edn are super immature and very broken, and they largely duplicate each other

this is the second broken uberjar building library I have diagnosed today (the other tool seemed to end up aot compiling things twice)

also, if you are not aot compiling you don't need the :gen-class

a new version of tools.deps is out now that probably makes it much harder to do the wrong thing with the install deps.edn

I dunno, this code literally just slurps the deps.edn and calls read-string on it

@drewverlee Try using depstar instead of uberdeps -- unless there's some specific feature you need from the latter?

well, if you're not using tools.deps at all, then yes, that's prob broken

Some of these packaging libs try to create a classpath which is not what you would have when running your code 😞

but I would encourage whomever to file tickets on these libs so they can be better, rather than raging about brokenness

(I hadn't even heard of uberdeps before just now)

I could be wrong too, I am just guessing at the problem

I am just suggesting, like, be aware of that state of maturity of a lot of these libraries(tools.deps is still new, so tooling built on it is even newer), and maybe vet them a little more before using them.

Well, vetting includes using, at least a little bit 🙂