Fork me on GitHub

I think one thing that would be really helpful would be if Cognitect could at least document a minimal, standard way to use t.d.a to get the project basis -- that's not entirely clear just from the API docs.

Alex Miller (Clojure team)00:12:54

Yeah, I have been thinking about just that

Alex Miller (Clojure team)00:12:22

Having just done it yet again for tree stuff :)


I think it's this code, but I'm not certain:

user=> (require '[ :as t])
user=> (keys (t/find-edn-maps))
(:root-edn :user-edn :project-edn)
;; -Srepro would omit user-edn here:
user=> (def deps (t/merge-edns (let [{:keys [root-edn user-edn project-edn]} (t/find-edn-maps)] [root-edn user-edn project-edn])))
;; if you want to apply aliases at the tool level:
user=> (def combined (t/combine-aliases deps [:test :runner]))
user=> (keys combined)
(:extra-paths :extra-deps :main-opts)
user=> combined
{:extra-paths ["src/test/clojure"], :extra-deps {org.clojure/test.check #:mvn{:version "1.0.0"}, com.cognitect/test-runner {:git/url "", :sha "f7ef16dc3b8332b0d77bc0274578ad5270fbfedd"}}, :main-opts ["-m" "cognitect.test-runner" "-d" "src/test/clojure"]}
user=> (def basis (t/calc-basis deps {:resolve-args combined :classpath-args combined}))

Alex Miller (Clojure team)00:12:07

The thing is you don’t necessarily want to do all of those steps

Alex Miller (Clojure team)00:12:32

It’s in parts so you can choose which ones to do


Yeah, if you don't need to apply aliases, you can omit the combined piece and pass an empty map to calc-basis?

Alex Miller (Clojure team)00:12:46

And modify in between if needed


(I'm cheating a bit with passing combined as both :resolve-args and :classpath-args there)

Alex Miller (Clojure team)02:12:06

Prerelease of Clojure tools • New option for `-X:deps tree`  - `:format :edn` to print the tree as edn data • Updated `-Stree` to also use the new format


Benefit of system property over depending on tda is that I can make deps.edn optional AND I don't need to bloat the classpath. I read the basis to locate output directories which tools namespace doesn't handle well.


I would prefer not to depend on tools.deps in clojure itself, but a decoupled system that can represent properties in EDN from whatever tool likes to put that in at startup. Comparable to System properties, but real data. E.g.:


Similarly spec could have been made optional with some more general hook system in the compiler for checking macros, possibly.

Alex Miller (Clojure team)13:12:03

certainly we'll not make clojure depend on tools.deps

Alex Miller (Clojure team)13:12:16

there is a basis api in the add-lib3 branch - some of that may move into either a very skinny lib or clojure itself tbd (that part would have no additional deps)

Alex Miller (Clojure team)13:12:32

is the *properties* idea above about :aliases or more generic?

Alex Miller (Clojure team)13:12:25

if not coming from :aliases, where do you imagine it's coming from?


> certainly we'll not make clojure depend on tools.deps <3 <3


About *properties*, I was thinking of a general way to set key/vals in a Clojure runtime, without having to deal with strings only (like in System/properties). This way you can avoid introducing more dynamic vars.


e.g. *command-line-args* could just be a key in that thing, and so could *clojure-version*


and perhaps :clojure-basis or :clojure/basis


And one could perhaps set them from the command line with{:a 1} so (= {:a 1} (:clojure/basis *properties*))

Alex Miller (Clojure team)15:12:55

I think you are glossing over potentially important details, but I'll keep it in mind


One benefit of a dynamic var would be binding it for different class loaders.