This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-07-11
Channels
- # announcements (6)
- # architecture (14)
- # babashka (26)
- # beginners (22)
- # calva (11)
- # clj-kondo (2)
- # clj-on-windows (1)
- # cljsrn (10)
- # clojure (116)
- # clojure-europe (5)
- # clojure-uk (1)
- # clojurescript (5)
- # cursive (9)
- # datomic (21)
- # depstar (1)
- # events (1)
- # fulcro (2)
- # graalvm (17)
- # graalvm-mobile (28)
- # helix (3)
- # introduce-yourself (2)
- # jobs (2)
- # lsp (4)
- # meander (1)
- # off-topic (4)
- # pathom (5)
- # polylith (6)
- # practicalli (5)
- # reagent (67)
- # reitit (1)
- # releases (2)
- # shadow-cljs (24)
- # tools-deps (23)
@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 tools.build
guide, it seems to indicate that the :build
alias would contain :deps {io.github.clojure/tools.build {:tag "v0.1.2" :sha "81f05b7"}
-- is that something specific to -T
? I would have expected :replace-deps {io.github.clojure/tools.build {:git/tag "v0.1.2" :git/sha "81f05b7"}
for a tool (`:replace-deps` instead of :deps
and :git/
qualifiers on the tag and SHA).
the :deps is coming from the merged deps.edn so is part of the input to the basis calculation
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 tools.build uses, might be wrong there
:deps and :replace-deps have always been synonyms in aliases
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
yeah, write-pom is still using :deps. that's the bug imo. logged as https://clojure.atlassian.net/browse/TBUILD-3
I tripped over this in tools.deps.alpha
BTW, not tools.build
, so I think this affects both libraries?
yes. I expect ultimately that the deps version is going to go away and build will be the way to do this
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 tools.build
in the future?
yes, I'm expecting the pom writing to eventually live only in tools.build 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?
currently, no, but I expect it's config to expand
these changes are not imminent
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.
clojure.tools.deps.alpha.gen.pom/sync-pom
specifically.
Yay me! I found a bug 🙂 Thanks for the other answers. And the :tag
vs :git/tag
Q observation @alexmiller?
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 tools.build.api
versions working locally -- still trying to decide whether I want to also expose the pom and aot stuff from -- the API for those two functions is too different from how depstar
as drop-in replacements for tools.build.api/write-pom
and tools.build.api/compile-clj
since they have a number of additional knobs and dials over the built-in versionsdepstar
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 tools.build
in the future?