This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-07-15
Channels
- # announcements (2)
- # babashka (27)
- # beginners (53)
- # boot (3)
- # calva (5)
- # cider (1)
- # clj-kondo (46)
- # cljdoc (38)
- # cljs-dev (40)
- # cljsrn (1)
- # clojars (5)
- # clojure (61)
- # clojure-europe (124)
- # clojure-germany (3)
- # clojure-losangeles (6)
- # clojure-nl (12)
- # clojure-uk (11)
- # clojurescript (44)
- # clojureverse-ops (7)
- # datomic (13)
- # events (3)
- # introduce-yourself (1)
- # jackdaw (5)
- # lsp (115)
- # malli (1)
- # off-topic (16)
- # polylith (2)
- # releases (1)
- # remote-jobs (6)
- # shadow-cljs (10)
- # sql (2)
- # timbre (1)
- # tools-deps (30)
- # vim (34)
- # xtdb (20)
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 tools.build
at this point? It has a javac
task.
I'm using tools.build 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
Ah, gotcha.
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.
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
Your prep-lib step is just running another alias, so to prep your root lib you just execute that alias from the command line
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.
New prerelease of the Clojure CLI is now available: 1.10.3.912 • 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
@alexmiller Should I expect this to give help on depstar
? clojure -A:deps -Tdepstar help/doc
-- it doesn't, it gives help on clojure.tools.cli.api
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]
Can you log these somewhere?
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 https://ask.clojure.org/index.php/10782/help-doc-would-be-useful-for-ttools since I don't know whether you'll want to reopen the ticket or create a new one.
Would this cause issues with server processes which use agents?
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.
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)
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.
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 tools.build
'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).
t.d.a's create-basis
is not going away
if you want to use find-edn-maps
and merge-edns
, then use them, they are part of the api
the only thing I said might go away is -Spom / -X:deps mvn-pom (I think)
Perfect! Thank you! Just wanted to make sure.