Fork me on GitHub
Alex Miller (Clojure team)20:11:01

I'm going to do a talk about tools.deps / clj next week at the conj - any burning questions I should be sure to answer?


Settle the debate on namespaces. Talk about java. Leak the plans for tools.ant

trollface 4

@alexmiller Talk about add-lib 🙂

Alex Miller (Clojure team)20:11:48

@dominicm if those are serious, I'm not sure what any of them mean

😛 4

I'm just teasing :) I was hoping tools.ant would give it away. Unless there really is a tools.ant...

Alex Miller (Clojure team)20:11:12

well, Lancet was kind of like tools.ant :)


It would be interesting to know if there's ideas you have that you'd like others to execute. (E.g. Expanding on Lancet, building X, the community would gladly step up and at the least explore the domain for you)

Alex Miller (Clojure team)20:11:58

yeah, I'll cover some future idea stuff for sure


In earnest, the big questions I've had are: - how do I do java - how do I do thing I do with lein (usually uberjar) - how do I load the tests of my dependencies (usually in the context of a monorepo) - why would I use this rather than lein

Alex Miller (Clojure team)20:11:29

"do java" == "compile java"?


Sorry, yes. How do I fold java into my program, or use java libraries from source. Stuff like that.


Good slide, yep :) (Although the team I said that to then introduced lein and took away all my lovely deps.edn)


Not so much "do java" but "do compile" in the presence of gen-class etc I think would be interesting to at least mention (`compile`, binding the output directory, making sure it exists).

👍 8
Alex Miller (Clojure team)20:11:28

you guys are too far on one end of the audience distribution :)

😄 4

These are really clojure questions, but is interesting how lein did all this stuff that we didn't understand. Even though it's simple to do yourself.

Alex Miller (Clojure team)20:11:20

but I will keep those in mind


I guess the recurring theme is "lein did X, deps.edn doesn't, where do I go?"

seancorfield20:11:59 -- does compile of a gen-class namespace (caveat about the compile target dir needs to exist). I don't think compile/AOT is that far too one end of the spectrum really -- lots of people seem to assume you need AOT because "everything" out there assumes :aot main.core and uberjar with a compiled -main 🙂 That's a big difference when you switch to CLI/`deps.edn` from the lein world (or even the boot world).


Intro to lein tends to be lein new app myapp; lein run; lein test; lein uberjar; java -jar path/to/the.jar -- so I think the equivalent story with CLI/`deps.edn` needs to be out there "officially" with at least some explanation of the differences.


(the current docs expect you to create your need project completely manually, for example, right?)


@alexmiller edited. Sorry, meant "create".

Alex Miller (Clojure team)20:11:36

create and deploy an artifact?

Alex Miller (Clojure team)20:11:24

"build" by itself is not a very precise word in this context


how to build your own lein with tools-deps 🙂


when TDEPS-116 will be solved 😄

Alex Miller (Clojure team)20:11:35

it'd be a lot better if that ticket talked about a problem, not a solution

Alex Miller (Clojure team)20:11:08

well, not by my reading


...just not very clearly: I want to author more fine-grained libraries that may have optional code/dependencies which won't bloat classpath when unneeded. With maven it can be done using classifiers. With gitlibs, it's all or nothing

Alex Miller (Clojure team)20:11:52

I have like 3 questions about every part of that statement


I'm ready to answer!

Alex Miller (Clojure team)20:11:42

but I'd suggest pulling the "optional code/dependencies" string as a place to start


I don't have an account there unfortunately, can't edit the issue.

Alex Miller (Clojure team)20:11:20

I don't have time to have a long conversation about this right now but something like that is a far better title/thing to describe in a ticket.

Alex Miller (Clojure team)20:11:05

"Allow specifying aliases in coordinates that point to deps.edn projects" is a specific change that might solve a problem, but unlikely to be the only possible change to solve those problems

✔️ 4
Alex Miller (Clojure team)20:11:24

Maven classifiers by themselves are just another dimension to your artifact coordinate (and tdeps already supports classifiers). They only get at this kind of a problem in combination with the Maven property system that allows you to conditionalize a dependency coordinate.


may be it's not worth saying to this audience, but does the following seem off? my general impression was that clj / deps.edn tries to address some key issues (e.g. pomegranate-related, git deps, etc.) and wasn't out to replace lein, boot, etc. i thought a somewhat natural path would be for existing tooling to start using clj / deps.edn (or tools.deps, gitlibs, etc.) to take advantage of its capabilities. iiuc, there are also new efforts to build on or make use of tools.deps + related:,, etc. i've used at least one lein plugin ( which, iiuc, makes use of gitlibs with varying degrees of success -- and iiuc there are other plugins (see the bottom of lein-git-down's README for some) that have made attempts. may be that these or similar things haven't "made it into the core of lein" is where some pain comes from?


If your future work part drops any hints about the more recent version of codeq tht you mentioned a few weeks ago in chat, you might be inundated with dozens of requests for more info, unless it is provided during your talk 🙂

Alex Miller (Clojure team)21:11:40

that has nothing to do with tools.deps so dont see why it would come up


@sogaiu I went down that path with boot-tools-deps but ultimately it was too difficult to meld t.d.a. and Boot due to their different worldviews on paths and dependencies for anything but the very simplest use cases. I don't know how lein-tools-deps fares in that regard.


I think if lein/`boot` adopted t.d.a. wholesale as their way to handle paths and dependencies at their core, then that "natural path" could happen -- but that's a lot of rework and potentially breaking as well.


And it's turned out that the effort that might have gone into that has perhaps gone into building tools on top of t.d.a. that provide the Leiningen-like features as point solutions you can mix'n'match (which is, to some extent, Clojure's general mindset). Both Leiningen and Boot are "easy" rather than "simple" because they are both "batteries included" -- which have served the community well for a long time but the CLI and the t.d.a.-based tools we have now feel more "Clojure-y" to me.


thanks for the insights


all "burning questions" for Alex to answer seem to be answered immetiately 🙂


I agree wholeheartedly with Sean, tools-deps are simple and that empowers me to quickly hack together tools I personally need, because I don't have to deal with semantics imposed by build tool


I think there is a lot of space for libraries to emerge that help with that process of developing projects


I made a couple of libraries with tools-deps, and the thing that wasn't there is aid to generate pom.xml, for example. clj -Spom is not enough — it's a good starting point, but my build scripts usually have to update different fields in pom, and dependency list provided by tools-deps might end up in different place... I'd like to see a tool that just helps me generating pom from data, and then I will use tools-deps programmatic APIs to provide information I need


Yeah, having a minimal pom.xml that satisfies the needs of clojars/cljdoc would be a big improvement over what -Spom produces by default but that would be a fairly simple tool to write I guess. Also something to update the version/tag in the POM file.


(shouldn't be core t.d.a./CLI functionality -- the community can easily build this... I just haven't quite felt enough pain yet to do write it myself 🙂 )


it seems metav just added POM generation with versioning just yesterday 🙂


I could probably even build that into clj-new to be honest so at least you start with a somewhat fleshed out pom.xml file...?


> Pom.xml generation >I have added the option to generate a pom.xml file based on what is already available from It actually uses the sync-pom function from tools deps then goes to the generated/updated pom and adds the group-id, artefact-name and version based on what metav already establishes.


this looks like it fits the bill


we are very happy users of metav so this is a welcome addition, maybe it would be nice to add this dependency to clj-new? We are mainly using it’s sha-based versioning but of course folks could use it for semver (who haven’t watched Spec-ulation 🙂 )

Alex Miller (Clojure team)22:11:51

I haven't looked at it in many years, but Maven actually has support for storing pom data in arbitrary formats and there was even a clojure format way back when this was conceived of

Alex Miller (Clojure team)22:11:25

maybe that's just taking on a lot more problems :)


Is there a dimension in which maven is not extensible?

😂 8