Fork me on GitHub

Hi guys, does anyone have a cljs tools-deps library I can look at? Trying my hand at it, but somehow the library can’t see itself. Lol


I'm interested in solving TDEPS-12, @alexmiller have you thought about how you'd like it to be done?


how to use clj cli compile java code


I have some java code in classpath

Alex Miller (Clojure team)16:09:21

@dominicm I don’t think anything on that ticket is very good thinking about this problem

Alex Miller (Clojure team)16:09:04

the problem is that the assumption going into the design is that there is a 1-1 correspondence between library name and artifact

Alex Miller (Clojure team)16:09:43

this is a case where that is not true

Alex Miller (Clojure team)16:09:14

everything else flows from that and without addressing that fundamental issue, there is no way to fix the issue

Alex Miller (Clojure team)16:09:13

I’ve been thinking about this for a long time and I think you have to solve the “name” part or you’re not fixing anything

Alex Miller (Clojure team)16:09:03

the library name here is used for dual purposes - identification in tools.deps, and lookup in Maven (the groupId:artifactId). In many places we key maps based on #1 so that really needs a new dimension of context that is more than just #2.

Alex Miller (Clojure team)16:09:48

that means encoding the classifier into the name (so you get uniqueness of identity) and have the Maven extension know how to decode that for lookup

Alex Miller (Clojure team)16:09:10

that could be done with a name encoding, or by using something other than a symbol as the library name


Interesting. When discussing with @malcolmsparks I dismissed the notion of using a vector or some encoding for the key. Something not mentioned is that there's more than just classifier as a dimension in Maven, there's also type. I suspect encoding is a bad solution because it's not information dense enough.

Alex Miller (Clojure team)16:09:11

would be an example idea for a symbol encoding


Sure. But then you have type too.

Alex Miller (Clojure team)16:09:42

tools.deps is about classpaths

Alex Miller (Clojure team)16:09:54

it is not about “providing a generic interface to all things Maven”

Alex Miller (Clojure team)16:09:30

the only type we care about is jars


Are we certain type isn't important? If so I agree that the symbol is the only important one. It would be a shame to use encoding, and then end up having to cram something additional in.

Alex Miller (Clojure team)16:09:09

give me an example where type is important

Alex Miller (Clojure team)16:09:32

(I’ve done this exercise and not come up with anything)

Alex Miller (Clojure team)16:09:04

another option is to support an expanded lib name like {:groupId "", :artifactId "artifactId", :classifier "classifier"}

Alex Miller (Clojure team)16:09:52

doing one does not preclude doing the other later


I don't have one to hand, that's certain. In that case I will defer to your data. My objection was weak and I was erring on the side of exposing everything in the case of not having access to any data.

Alex Miller (Clojure team)16:09:04

tools.deps has been out for about a year and I haven’t seen a request or question about anything other than classifiers


If we did that, would it be a consistent return value? I'm guessing it would involve changing the current lib map spec?

Alex Miller (Clojure team)16:09:22

what is “it” in above?


The map version of the lib name.

Alex Miller (Clojure team)16:09:26

yes, would change (grow) the spec and a couple things in the Maven extension canonicalization

Alex Miller (Clojure team)16:09:49

I really need to talk to Rich to make a decision on that


At the moment I rely on it being a symbol in pack, in order to perform naming. That seems like a breaking change for me. Am I relying on a property I shouldn't?

Alex Miller (Clojure team)16:09:38

the code changes are pretty trivial. thinking clearly about the problem here is the important part.

👍 8

> choose whatever name you want with lowercase letters and no strange symbols. I was just looking into which character was appropriate. Maven is surprisingly coy about what is allowed...


I guess I will just have to test.


lol so I blew out ~/.m2 and now when I try and run clj:

Error: Could not find or load main class clojure.main


@lilactown I'm guessing because the classpath is cached

Alex Miller (Clojure team)17:09:02

yes, if you manually muck with .m2, you’ll need to use clj -Sforce

Alex Miller (Clojure team)17:09:27

currently clj does not do any checks to verify that all the dirs/files on the classpath exist

Alex Miller (Clojure team)17:09:37

I’m a bit on the fence about it - that could be added, but has the downside of a) adding startup time and b) not being tolerant of (for example), a missing src path on the cp. although I guess you could maybe only check the files.


Maybe just a warning to “if in doubt, clj -Sforce” on “missing” errors?

☝️ 4

yeah, I didn’t know about -Sforce. that would be a helpful enhancement


Or, could do the path checking AFTER the error occurs, in which chase “start up time” isn’t a factor.


Verify that there are missing paths for a good error message, not re-do the whole op.

Alex Miller (Clojure team)19:09:12

the benefit of doing it before is that you can potentially fix it, not error

Alex Miller (Clojure team)20:09:17

if stuff is stale, then force

Alex Miller (Clojure team)20:09:27

the question I’d like to answer is - how long does it take to do the check for a reasonable size classpath


Right. The “after” idea is to keep the speed benefits, but provide a clearer option for the user to try: same as it is now, just slightly clearer.