Yep, that's the one

@hugh336: Yeah it would be really useful if there was a variant on -Sdescribe that didn’t attempt to resolve your dependencies etc, and only returned the information that is known locally about the installation. As for us in lein-tools-deps this means that we end up resolving aliases twice once when we don’t really want to

I don’t think there’s a good way around this without changing tools deps / or the clj/clojure command line project.

there is actually a flag buried in the underlying clojure program to tell it not to resolve

but it’s not surfaced out to the top

I’d be happy to have a ticket about the problem in TDEPS so I can think about a solution

what is the flag?

https://github.com/clojure/tools.deps.alpha/blob/master/src/main/clojure/clojure/tools/deps/alpha/script/make_classpath.clj#L30

if set, that avoids doing the resolution, making a classpath, and saving those off

was added for some stuff Stu was doing (in the guts of ion impl) where similar need arose

Interesting… I thought the issue was here as we shell out to run -Sdescribe https://github.com/clojure/brew-install/blob/1.9.0/src/main/resources/clojure#L320-L332 though I could be misunderstanding the flow

yes, this flag is at a lower level and not exposed at the script level as I mentioned above

cool… we can look at registering an issue

wait, -Sdescribe doesn’t resolve anything

so I will go all the way back to the top of this discussion and disagree with the premise

lol ok 🙂

so this: “Yeah it would be really useful if there was a variant on -Sdescribe that didn’t attempt to resolve your dependencies etc, and only returned the information that is known locally about the installation.” is not correct

that’s exactly what -Sdescribe does

ok it’s not what we’re seeing… maybe there’s something else causing us to misdiagnose the problem though

well maybe there’s a bug there

looking at the script, could definitely be but it’s just a matter of another flag check before resolving

so, I’d say that’s the ticket to file - ensure -Sdescribe doesn’t trigger resolution

@rickmoynihan @alexmiller Thanks for the discussion, I'll file a ticket

sorry for my densitude

not at all, you must be pulled every which way

@alexmiller One other thing it looks like when using tools.deps as an API we don’t get the caching behaviour because it’s trapped inside the shell script here: https://github.com/clojure/brew-install/blob/e706dbedbe91446ae0a09ff32fd36620cc966c55/src/main/resources/clojure#L238 I understand it’s probably there because it avoids you having to start another VM, but it seems to mean we don’t get the libs caching in our plugin. Is there a clj implementation of this somewhere, or do we need to write one?

Hey… I’m using this org.imgscalr/imgscalr-lib {:local/root "libs/imgscalr-lib-4.3.jar"} But when I do uber with boot, using seancorfield/boot-tools-deps, this jar is not extracted and added to the standalone jar, how do I do it, this is my boot command

BOOT_CLOJURE_VERSION=1.9.0 boot -d seancorfield/boot-tools-deps:0.4.5 \
                                        boot-tools-deps.core/deps -B \
                                        pom -p "zzk/catalog-image-svc" -v "0.0.1" -d "ZZK image processing" -u "" -l "X:X" \
                                        uber \          
                                        jar -m clojure.main \
                                        target  

@rickmoynihan @alexmiller Ticket created https://dev.clojure.org/jira/browse/TDEPS-82

thx

@rcustodio Does it work (run) if you use just clj, not boot? Can you build a JAR with depstar or pack?

Yes, it works with run

clj run

depstar pack, i dunno what that is

Can you put the project up on GitHub so I can clone it and try it out?

depstar and pack are clj-based utilities to create uberjars.

hmm.. I can’t because its a in-company project

That is my deps

{:aliases
 {:deps {:extra-deps {org.clojure/tools.deps.alpha {:mvn/version "0.5.435"}}},
  :test {:extra-paths ["test"]}},
 :deps
 {br.com.vikingmakt/augustus {:mvn/version "0.1.12"},
  br.com.vikingmakt/njord {:mvn/version "0.3.0"},
  cheshire {:mvn/version "5.8.0"},
  clj-time {:mvn/version "0.14.4"},
  com.novemberain/langohr {:mvn/version "5.0.0"},
  com.novemberain/monger {:mvn/version "3.1.0"},
  net.mikera/imagez {:mvn/version "0.12.0"
                     :exclusions [org.imgscalr/imgscalr-lib]},
  org.apache.logging.log4j/log4j-core {:mvn/version "2.11.0"},
  org.apache.logging.log4j/log4j-slf4j-impl {:mvn/version "2.11.0"},
  org.clojure/clojure {:mvn/version "1.9.0"},
  org.clojure/tools.logging {:mvn/version "0.4.1"},
  org.imgscalr/imgscalr-lib {:local/root "libs/imgscalr-lib-4.3.jar"}},
 :mvn/repos
 {"central" {:url ""}, "clojars" {:url ""}},
 :paths ["resources" "src/main/clojure"]}

And that imgscalr-lib is your own custom in-house version?

nope, I just got the last (master) from the github repository

Because I’m using something that is not in the latest version from http://maven.org

I will try it out with depster

@rcustodio can you add -vv after -B on the deps task and send me the output via DM here? No point in clogging up the channel with it.

okey

You can find links to Depstar, Pack, and other tools.deps tooling here: https://github.com/clojure/tools.deps.alpha/wiki/Tools

Not sure if this is a tools-deps problem but if I don't have AWS_ACCESS_KEY and AWS_SECRET_ACCESS_KEY set as env vars, I get a access denied from a Maven repo. I am specifically trying to access the Datomic cloud repo "" which, I assume, does not require authenticated access.

Yeah, same is under discussion in #datomic - I’m going to dig into it a little more