This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-07-26
Channels
- # aws-lambda (15)
- # babashka (7)
- # beginners (124)
- # calva (7)
- # cider (19)
- # clj-kondo (26)
- # clojure (261)
- # clojure-australia (3)
- # clojure-dev (10)
- # clojure-europe (45)
- # clojure-nl (4)
- # clojure-uk (6)
- # clojurescript (10)
- # datomic (7)
- # depstar (7)
- # emacs (11)
- # fulcro (41)
- # graalvm (48)
- # helix (1)
- # honeysql (17)
- # inf-clojure (7)
- # introduce-yourself (3)
- # jackdaw (2)
- # lsp (36)
- # malli (2)
- # meander (2)
- # membrane (1)
- # missionary (11)
- # off-topic (17)
- # pathom (83)
- # polylith (15)
- # re-frame (31)
- # reagent (42)
- # sci (35)
- # shadow-cljs (13)
- # spacemacs (13)
- # sql (19)
- # timbre (3)
- # tools-deps (77)
There seems to be a weird issue related to -X
and futures with Clojure CLI 1.10.3.929:
$ clojure --version
Clojure CLI version 1.10.3.929
$ clojure -Srepro -X clojure.core.server/start-server :name '"server"' :port 5555 :accept clojure.core.server/repl :server-daemon false
$ clojure -Srepro -J-Dclojure.server.repl="{:port 6666 :accept clojure.core.server/repl}"
$ nc localhost 5555
user=> (def x (future 1))
Execution error (RejectedExecutionException) at java.util.concurrent.ThreadPoolExecutor$AbortPolicy/rejectedExecution (ThreadPoolExecutor.java:2057).
Task java.util.concurrent.FutureTask@14c75e2b[Not completed, task = clojure.core$binding_conveyor_fn$fn__5772@4f4cba65] rejected from java.util.concurrent.ThreadPoolExecutor@5d5b17a8[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 1]
$ nc localhost 6666
user=> (def x (future 2))
#'user/x
That is, future
throws when connecting to a socket REPL server started via -X
, but not when connecting to a socket REPL server started via the clojure.server.repl
system property.The -X
invocation doesn't work at all on 1.10.3.882, so I can't (easily) narrow it down any further.
I can repro but can't explain the difference @U4ZDX466T You should put this up on http://ask.clojure.org so it doesn't get lost as Slack drops history.
What's your take on putting aliases within project deps.edn vs home's .clojure/deps.edn? I understand that some of the tools vary among Clojure devs (REBL/reveal, srepl/nrepl, IDEs/editors), so make sense to keep them locally specific, but lots of stuff could be shared, plus it is nice to have a sensible defaults for any newcomers. What your thoughts on this one? What kind of aliases do you shares within your projects' deps.edn?
@grzegorz.rynkowski I think the project deps.edn
should contain only aliases relevant to the project itself. If you want a "shared .clojure/deps.edn
file", create a separate repo for that (and, now, any standard "tools" you want them to have installed, if you're starting them on the latest prerelease), and have them set up their environment based on that.
I don't know the right answer to "I want to check my emacs settings into your open source project so it does the right thing when I open CIDER", but I generally tell people to just document this for whoever wants to use it, instead of committing it in the project
On the the other hand, I sometimes see some IDEA settings in open source Clojure or Java projects π€·
But when it comes to .lsp or .clj-kondo config, I do think it belongs into the project, since it's about the code itself and improves the tooling related to the code.
@deleted-user as an aside: I avoid the usage of the magic "jack-in" stuff
why? because I don't want to have my dev process as a child of whatever editor. when I close my editor or open a too big of an XML file, I have to restart my dev process. too brittle.
My team start their REPL and then connect their editor to it. It's definitely our preferred approach. Partly because REPLs tend to outlive the editor and partly because you know exactly how the REPL is getting started instead of some "jack-in magic".
(and this really isn't about #tools-deps stuff -- greg's original Q was)
although I am using them, they are a bit magic when it comes to whatever profile is active when
A jar doesn't have system properties set. You have to set those when you invoke the jar, I think?
for those dev tooling, i'd probably just check if those namespaces were available, and if so, use the middleware with requiring resolve. Then jars wouldn't have those dev deps and you don't even need to configure anything
@deleted-user you want specific ring middleware for development, is this the problem?
I would put the dev-specific stuff in a :dev
alias and use that when developing (and it would be omitted when building the JAR).
I don't see how this related to lein or deps.edn specifically, but there are ways to get this done through a dev profile/alias
Jack-in can be told to use aliases.
But my advice would be to stop using "magic".
I don't recommend the jack-in stuff but I think you can configure the tooling to use a specific alias ;)
It's much harder to optionally exclude stuff than to optionally include other stuff.
you can ask in #clojure or somewhere. we can help you through things. But seems like this is getting towards generic project management rather than specific tools-deps questions
Re: JAR building -- if you can get to the place where you use -M:dev
for dev/test and -M:prod
for production, you can use the :prod
alias when building the JAR.
@deleted-user if you need to persist settings in a jar, the only way is to flush them to a file in the resources, e.g. under META-INF/my-tool/settings.edn
when you (def foo (System/getProperty "build.time-property"))
this won't be captured and written into the jar somehow
(for what it's worth, we run our code in dev/test, the same way it would run in production -- without any special middleware etc -- partly to avoid these problems and also, mostly, to avoid "works-in-dev, break-in-production" issues)
was gonna ask this on http://ask.clojure.org but i don't see a category for tools.build in the dropdown and that's giving me pause if that's a good place for prerelease version. But i'm observing the following error > /var/folders/h/3fpgc8pj4fb2w3mfqfl59fr0000gn/T/uber10889152638484484/license/LICENSE (Not a directory) and the stacktrace
build=> (b/uber {:class-dir class-dir
:uber-file "uberjar.jar"
:basis basis})
FileNotFoundException /var/folders/_h/3fpgc8pj4fb2_w3mfqfl59fr0000gn/T/uber5850854519152411962/license/LICENSE (Not a directory)
java.io.FileOutputStream.open0 (FileOutputStream.java:-2)
java.io.FileOutputStream.open (FileOutputStream.java:298)
java.io.FileOutputStream.<init> (FileOutputStream.java:237)
java.io.FileOutputStream.<init> (FileOutputStream.java:187)
clojure.tools.build.tasks.uber/explode (uber.clj:66)
clojure.tools.build.tasks.uber/explode (uber.clj:53)
clojure.tools.build.tasks.uber/uber/fn--16677 (NO_SOURCE_FILE:636)
clojure.core/run!/fn--8813 (core.clj:7717)
clojure.core.protocols/naive-seq-reduce (protocols.clj:62)
clojure.core.protocols/interface-or-naive-reduce (protocols.clj:72)
clojure.core.protocols/fn--8181 (protocols.clj:169)
clojure.core.protocols/fn--8181 (protocols.clj:124)
Out of curiosity, if you add depstar
as a library, and use hf.depstar.api/uber
instead of t.b.api/uber, does it work? (It should be API-compatible)
Per https://cljdoc.org/d/com.github.seancorfield/depstar/2.1.267/doc/tools-build-usage if you aren't sure what I mean...
Could be. I think there's already a bug open against t.b.a/uber for problems with multiple instances of a file.
It doesn't concatenate license or notice files right now (it should). It doesn't handle log4j2 plugin cache files either. But I think that's all on the roadmap.
The end goal is, in theory, that depstar
can be retired in favor of t.b.a π
depstar worked a treat. i think the filesystem as an intermediate can be tricky when going from case sensitive jars, possibly case sensitive FS, back to case insensitive jars
@U11BV7MTK If you're on Windows, try building an uberjar with tools.build
for a project that depends on uncomplicate/neanderthal
π
It contains an aux.clj
file, which is a reserved name on Windows -- so you can't explode the neanderthal library to a directory and then copy it all into a JAR.
https://github.com/seancorfield/depstar/issues/8 -- that was a big part of why I stopped doing that step.
(I haven't checked whether Neanderthal has renamed that namespace - it might have)
haha that is not fun at all π. i don't have access to a windows box unfortunately though
I do but it isn't set up for Clojure on the Windows side -- only on the WSL2 side, otherwise, I'd verify that the above issue exists with tools.build
and log a bug if it still happens...
@U04V70XH6 I renamed aux.clj to auxil.clj long time ago (due to this unfortunate Windows behavior).
@U086AG324 Good to know! Thank you! It's weird that after all these decades, Windows still treats several filenames as reserved...
i think that's really cool of them to take backwards compatibility so seriously. gotta respect that com binaries from the 80s still run on windows 10
looks for an emoji for stagecoach or something similarly old... π
it seems this is from the jar .m2/repository/xml-apis/xml-apis-ext/1.3.04/xml-apis-ext-1.3.04.jar
which has an entry for license/LICENSE.
I'd say put it on ask with the tools.deps category...
And I see tools.build under Contrib so you should be able to tag it that way.