Fork me on GitHub

@alexmiller Q about basis calculation: I'm not sure if this is a bug, but it caught me out (and was raised as a bug against depstar). If you call create-basis with :aliases, the :deps entry in the basis you get back does not reflect any :extra-deps in those aliases -- but it does reflect :replace-deps from those aliases. I was using that basis as the argument to t.d.a's sync-pom which only uses :deps and :paths when constructing the pom.xml file, so when depstar tried to create/sync a pom file, it looked as if :aliases were being ignored. My "fix" for this in depstar is to do the following:

(let [{:keys [resolve-args] :as basis}
          (t/create-basis (cond-> {:aliases aliases}
                            repro (assoc :user nil)))]
      (update basis :deps merge (:extra-deps resolve-args)))
so that when I pass that to sync-pom, the :deps entry includes the :extra-deps from the :aliases and they appear in the <dependencies> section, which is what users expect. It seems that if you do clojure -A:some:aliases -Spom, the behavior is correct: any :extra-deps from those :aliases do end up in the pom.xml file (presumably because they are added to :deps by the time sync-pom is called?) so this feels like a bug in t.d.a to me.


In the guide, it seems to indicate that the :build alias would contain :deps {io.github.clojure/ {:tag "v0.1.2" :sha "81f05b7"} -- is that something specific to -T? I would have expected :replace-deps {io.github.clojure/ {:git/tag "v0.1.2" :git/sha "81f05b7"} for a tool (`:replace-deps` instead of :deps and :git/ qualifiers on the tag and SHA).

Alex Miller (Clojure team)21:07:09

the :deps is coming from the merged deps.edn so is part of the input to the basis calculation

Alex Miller (Clojure team)21:07:25

for the deps to use when writing a pom, you should really use the root deps from :libs (the output of the basis). I'm not sure what write-pom in uses, might be wrong there

Alex Miller (Clojure team)21:07:47

:deps and :replace-deps have always been synonyms in aliases

Alex Miller (Clojure team)21:07:50

we had basically switched to making :replace-deps the primary but when using it with -T, :deps makes more sense to me - this is something I'm still thinking about

Alex Miller (Clojure team)21:07:02

yeah, write-pom is still using :deps. that's the bug imo. logged as


I tripped over this in tools.deps.alpha BTW, not, so I think this affects both libraries?

Alex Miller (Clojure team)13:07:29

yes. I expect ultimately that the deps version is going to go away and build will be the way to do this

Alex Miller (Clojure team)16:07:35

fixed TBUILD-3, and also updated similar code for clj -X:deps mvn-pom , clj -Spom was already doing this


Interesting. So the expectation is that tools like depstar and clj-new that currently depend on t.d.a and calculate a basis would instead depend on in the future?

Alex Miller (Clojure team)18:07:20

yes, I'm expecting the pom writing to eventually live only in and to phase out the -Spom and -X:deps mvn-pom options


Hmm, I would want more control over where the pom.xml file gets written before I could switch over, I think. Doesn't write-pom put the file into Maven-style directory structure? Can it update-in-place, like -Spom currently does?

Alex Miller (Clojure team)18:07:00

currently, no, but I expect it's config to expand

Alex Miller (Clojure team)18:07:36

these changes are not imminent

Alex Miller (Clojure team)18:07:14

are you using -Spom or -X:deps mvn-pom right now?


No, because I use t.d.a as a library (in depstar) to update a pom.xml in place or write it to a specific target directory.

seancorfield18:07:34 specifically.


Yay me! I found a bug 🙂 Thanks for the other answers. And the :tag vs :git/tag Q observation @alexmiller?

catjam 2
Alex Miller (Clojure team)13:07:26

I haven't had a chance to look into it yet


(I have hf.depstar.api/jar and hf.depstar.api/uber as drop-in replacements for the versions working locally -- still trying to decide whether I want to also expose the pom and aot stuff from depstar as drop-in replacements for and since they have a number of additional knobs and dials over the built-in versions -- the API for those two functions is too different from how depstar currently works so I've cleaned up hf.depstar so that it can offer an alternative "build" approach via -X/`-T` or in a build.clj script... but now I need to write a lot more documentation!)


Interesting. So the expectation is that tools like depstar and clj-new that currently depend on t.d.a and calculate a basis would instead depend on in the future?