Fork me on GitHub
Cam Saul00:07:18

one more (probably dumb) question: is there a way to deps prep a top-level deps.edn project? My main use case in compiling a Java file in a project similar to what Leiningen :java-source-paths does -- my workaround was to add a separate java/deps.edn (with the :deps/prep-lib key) and then have the top-level deps.edn include ./java as a :local/root dependency. Not such a huge deal, but since compiling the Java source file requires some dependencies already specified in the top-level deps.edn I ended up having to have a few duplicate deps between deps.edn and java/deps.edn


@camsaul Sounds like you should be using at this point? It has a javac task.

✔️ 8
Cam Saul00:07:54

I'm using javac as part of the :deps/prep-lib step. The problem is I want that prep step to run (or at least fail with the error saying it needs to be ran) before doing anything -- running tests, starting a REPL, etc. The prep step works fine if I create an extra deps.edn file in my Java source dir and refer to it as a :local/root dep, I'm mainly asking if there's a way to do it without creating the extra deps file to avoid having to specify duplicate deps in both the top-level deps.edn and the extra one I created in my ./java source dir


Wait, the prep lib stuff is only going to run once -- and then the dependency is "prepped" -- so it won't run when you change the Java code or anything like that.

Cam Saul00:07:58

yup, but that's fine with me for the time being. At Metabase we have exactly one Java source file (we use Liquibase for app DB migrations and the file is a custom class subclassing a generic class that forces it use the utf8mb4 collation when creating new tables MySQL/MariaDB, so it basically has to be there and be compiled before doing anything else). I wrote that file maybe 4 years ago and haven't touched it since. My main motivation is so that anyone who clones the git repo and tries to run it locally doesn't need to jump thru too many hoops to do it. clojure -X:deps prep && clojure -X:run (or whatever the new multiple-function equivalent of that is) is fine for now -- and I have that more or less working -- but having to specify the Liquibase dependency twice in two separate deps.edn files makes me a little itchy

Joshua Suskalo13:07:20

Your prep-lib step is just running another alias, so to prep your root lib you just execute that alias from the command line

Joshua Suskalo13:07:42

And if you want to ensure that alias is run only once, then make it take a :force key you can provide from the command line, and if it isn't provided, then it'll create a lockfile and ensure it won't run again.

👍 2
Alex Miller (Clojure team)14:07:31

New prerelease of the Clojure CLI is now available: • Fix help/doc and help/dir to better load namespaces • TDEPS-187 - Make help/doc and help/dir work with tools via something like: ◦ clj -A:deps -Ttool help/dir • Fix -X/-T to use (agent-shutdown) instead of (System/exit 0) on success to avoid forced exit for server processes

👍 14

@alexmiller Should I expect this to give help on depstar? clojure -A:deps -Tdepstar help/doc -- it doesn't, it gives help on instead.


These work

505  clojure -A:deps -Tdepstar help/doc :ns hf.depstar
  506  clojure -A:deps -Tdepstar help/doc :fn hf.depstar/pom
but given that depstar has :ns-default I would have expected the above to work.


Also, :deps/`-T` is not very friendly with tools that do their own logging due to the slf4j no-op lib:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/Users/sean/.m2/repository/org/slf4j/slf4j-nop/1.7.25/slf4j-nop-1.7.25.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/Users/sean/.m2/repository/org/slf4j/slf4j-simple/1.7.30/slf4j-simple-1.7.30.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See  for an explanation.
SLF4J: Actual binding is of type [org.slf4j.helpers.NOPLoggerFactory]

Alex Miller (Clojure team)16:07:30

Can you log these somewhere?

Alex Miller (Clojure team)16:07:21

Just in general, if you have a bug please report it in something I can track rather than here. I am just beyond my ability to track all the things


I wanted to check whether you expected it to work, i.e., that it is a bug, first... I'll put it on ask now.


I added a comment to since I don't know whether you'll want to reopen the ticket or create a new one.

Joshua Suskalo15:07:06

Would this cause issues with server processes which use agents?

Alex Miller (Clojure team)15:07:21

that's not common (and they would already be in trouble with the prior impl which hard exited). they would need to block the main thread from exiting.

Alex Miller (Clojure team)15:07:56

the thing we're trying to avoid above is an early exit when a server has non-daemon threads still active (socket repl server being the obvious case)

Joshua Suskalo15:07:08

Aaah, makes sense.


@alexmiller While I remember: I have a use case for wanting just the various deps.edn read and merged -- reading :alias data, without actually resolving deps, so t/find-edn-maps and then t/merge-edns without any additional steps. This cropped up with depstar which I had switched to t/create-basis for that and it caused problems for someone in CI who was passing a custom basis into the tool.

Alex Miller (Clojure team)15:07:45

I’m not understanding what you’re asking for


t/create-basis causes deps to be downloaded, yes?


t/find-edn-maps & t/merge-edns don't. And that's important for the user that reported the bug. This is in the context of you saying t.d.a's create-basis might go away in favor of's version, and I just wanted to point out that EDN manipulation is a likely use case for tooling, without full calculation of a basis (and downloading stuff).

Alex Miller (Clojure team)16:07:21

t.d.a's create-basis is not going away

Alex Miller (Clojure team)16:07:58

if you want to use find-edn-maps and merge-edns , then use them, they are part of the api

Alex Miller (Clojure team)16:07:57

the only thing I said might go away is -Spom / -X:deps mvn-pom (I think)


Perfect! Thank you! Just wanted to make sure.