Clojurians Log v2

It is intentionally not yet documented

As we are probably going to add some api around it

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.

Yeah, I have been thinking about just that

Having just done it yet again for tree stuff :)

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

user=> (require '[clojure.tools.deps.alpha :as t])
nil
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])))
#'user/deps
;; if you want to apply aliases at the tool level:
user=> (def combined (t/combine-aliases deps [:test :runner]))
#'user/combined
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 "<https://github.com/cognitect-labs/test-runner>", :sha "f7ef16dc3b8332b0d77bc0274578ad5270fbfedd"}}, :main-opts ["-m" "cognitect.test-runner" "-d" "src/test/clojure"]}
user=&gt; (def basis (t/calc-basis deps {:resolve-args combined :classpath-args combined}))
#'user/basis

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

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?

And modify in between if needed

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

I’ve been super impressed with antq too. Big 👍 from me!

Prerelease of Clojure tools 1.10.1.749 • 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.: https://clojurians.slack.com/archives/C6QH853H8/p1607297023257300

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

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

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)

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

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 -J-Dclojure.property.clojure/basis={:a 1} so (= {:a 1} (:clojure/basis *properties*))

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.