I'm not sure if this is a known issue, but tools.build doesn't work with Potekmin defprotocol+ (which skips redefining the underlying var/interface class if it already exists) -- at least not in cases where another namespace that require the one defining the defprotocol+/etc. come before the one defining it alphabetically. For example, suppose I have a namespace stuff :

(ns stuff
  (:require stuff.protocols))

(ns stuff.protocols
  (:require [potemkin :as p]))

(p/defprotocol+ MyProtocol ...)

(binding [*compile-path* "/tmp/compile-clj9219850936397513089/compile-clj"] ; number is random for each run
  (compile 'stuff)
  (compile 'stuff.protocols))

(require 'potemkin.macros)
(intern 'potemkin.macros 'equivalent? (constantly false))

# with tools.build
$ jar -tf target/uberjar/metabase.jar | wc -l
102171
$ jar -tf target/uberjar/metabase.jar | grep metabase.util.i18n.impl | wc -l
51

# with Leiningen
$ jar -tf target/uberjar/metabase.jar | wc -l
94706
$ jar -tf target/uberjar/metabase.jar | grep metabase.util.i18n.impl | wc -l
33

You can specify the namespaces to compile in order with compile-clj - did you try that?

It’s not expected that the default will work for every library, particularly for issues like this

we have a little over 400 namespaces for Metabase, so it's a bit too much to do by hand. Let me try programmatically determining the appropriate compile order for them and seeing if tools.build works without the hacks if I do that

Ok, by passing in the namespaces in topological order (I basically just copied the Cloverage code I wrote last year to do it programmatically) it does actually work without the hacks, and doesn't create any duplicate files. The bad news is my build.clj file is ~200 LoC now (just to replicate lein uberjar -- nothing else like install or jar). Not so bad for me since I've been writing Clojure around 9 years now but I feel like potentially writing that much code to deploy a project has the potential to trip up newcomers to the language

We probably have tools namespace on the class path. Can’t that topo sort them?

Just generate a dummy file that requires all your namespaces and only compile that file

imo anything that calls compile more than once is going to break things

If you do the dummy file you don't need to sort anything

something like https://github.com/hiredman/tools.build/commit/3709c1b9748519a373908528406fccbb86b678fb

Hey, I am using the prerelease cli 1.10.3.905 and I am having a dependency that points to a local jar via :local/root . I am getting the error

Error building classpath. Manifest type :jar not loaded when finding deps for ... in coordinate ...

Just wanted to +1 the conversation about compilation order. I think I hit a similar issue as @camsaul just yesterday. I have bit more detail https://stackoverflow.com/a/68413578/4297413.

Should -x:deps find-versions be working for Clojure CLI version 1.10.3.855? it says function not found: clojure.tools.cli.api/find-versions, asking because the example is in the docs already 🙂

no, only working in prerelease

docs should probably guard that, but I'm hoping it's not more than a week or so till things come back together

Is there a way in deps.edn to set that the type of my dependency is pom only? Like this one https://mvnrepository.com/artifact/io.zonky.test.postgres/embedded-postgres-binaries-bom/13.2.0

no, that's not supported in deps.edn