You might be able to use the -Scp option to pass it a pre-built classpath so it just uses what is specified without trying to download anything.

Ah yah, so -Spath and then java -cp … clojure.main -m xyz`` i’ll give it a shot

Yeah, you could run bare java -cp with the saved result of -Spath. But clj itself has a -Scp option in case you need to run Clojure tools without recomputing/fetching anything.

(you mentioned clj -M so I figured you were trying to do something specific with :main-opts)

clj won't even run the process that has access to the code to fetch deps unless it hasn't computed the classpath for your deps.edn yet

Which is what -P is for

if i run -P, but then change the deps.edn it does a network call right

Right

so that was the basis of my concern, you’re saying it won’t do a network call if deps.edn has the same content

Depends what you mean by same content, if the bytes hash the same (so whitespace and comments, etc count)

You need to make sure you are using the same set of aliases as well

gotcha… well excellent, that’s what I was hoping for

I was playing with something like that in the past. And I think there is no guaranty that clj does not "try" to access the network. The -P is more for "reducing download time" then to guarantee that no network call occur, I believe. Maybe worth to check with clojure.core team.

There are a few cases in which tools.deps will always hit the network, regardless of what is cached. The one we've ran into most often is https://clojure.atlassian.net/browse/TDEPS-223. That particular issue can be worked around by making all the git deps use full hashes and no tags.

Offline builds are not really a design goal I think, so you need a few tricks to make them work. Alternatively you can run a pre-populated git + maven caching proxy within your sandboxed build, but that's a bit more involved.