This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-08-02
Channels
- # announcements (11)
- # aws (3)
- # babashka (34)
- # beginners (20)
- # biff (2)
- # calva (3)
- # cherry (29)
- # cider (6)
- # cljs-dev (9)
- # clojure (124)
- # clojure-europe (12)
- # clojure-norway (5)
- # clojure-uk (2)
- # clojurescript (32)
- # conjure (11)
- # datalevin (1)
- # datomic (16)
- # deps-new (1)
- # etaoin (6)
- # holy-lambda (10)
- # honeysql (28)
- # hyperfiddle (21)
- # jackdaw (2)
- # jobs (2)
- # leiningen (15)
- # missionary (12)
- # off-topic (132)
- # other-languages (1)
- # pathom (13)
- # rdf (10)
- # re-frame (8)
- # reagent (5)
- # releases (1)
- # remote-jobs (4)
- # shadow-cljs (32)
- # tools-deps (6)
- # vim (15)
- # xtdb (24)
Hi, I’m using an nrepl task I copied from the book
nrepl (do (srv/start-server! {:host "localhost"
:port 1667})
(spit ".nrepl-port" "1667")
(-> (Runtime/getRuntime)
(.addShutdownHook
(Thread. (fn [] (fs/delete ".nrepl-port")))))
(deref (promise)))
but when I try and eval a ns form which requires the hasch library I get
; (err) : Can't set!: clojure.core/*warn-on-reflection* from non-binding thread
I know hasch works because I can run it from the command line fine, so I think this is some issue with the task I’m using to start the nrepl server?
Any ideas?I think you could fix this by doing:
(binding [*warn-on-reflection* *warn-on-reflection*] ...)
around the call to srv/...
for nowok if you unzip this and run
bb -m foo
it will work ok, if you run
bb nrepl
then connect and eval the buffer (or just the ns form) it will give the error. I added the binding but same thingThis worked for me:
user=> (binding [*warn-on-reflection* *warn-on-reflection*] (require '[hasch.core]))
nil
This is a repro, just eval this in nREPL:
user=> (set! *warn-on-reflection* true)
: Can't set!: clojure.core/*warn-on-reflection* from non-binding thread user
Alright so as a workaround I can just put that binding in my ns? I’ll make an issue
this is a clj-kondo question really, but is there something I can do so kondo recognises require
outside a ns?
you can just repeat the require a second time. for bb isn't a no-op but for clj-kondo it will work
I was able to extract the code for my much more verbose take on command line option/argument parsing: https://github.com/hlship/bb-tasks
Looks really neat. Feel free to PR it to the toolbox :) https://babashka.org/toolbox/
To do something similar with args in bb cli you could do: https://gist.github.com/borkdude/29926d5ece9f79b04629a822fdc4e011
So, right now, the bb.edn contains
{:doc "Configures the system with keys and values"
:task (t/configure)}
If just bare, t/configure
, then BB will attempt to convert command line args and call the wrong arity:
> bb configure pages=10 skip=true -v
----- Error --------------------------------------------------------------------
Type: java.lang.Exception
Message: Cannot call configure with 4 arguments
>
But what if the task code looked at the meta-data for #'configure
to:
• to see that it should invoke the 0 arity implementation
• to extract the :doc
(which can be provided by deftask
from the docstring (DRY)I've given it some more thought and realized that what I want is an alternate to Babashka tasks as I'm trying to build reusable tools, often with sub-commands.
Right. Babashka tasks is mostly focused on project-local task (akin to Makefile). #babashka-neil is a tool that uses the sub-command feature from babashka CLI heavily
It's now called cli-tools
https://github.com/hlship/cli-tools
Personally I always found writing boot tasks too verbose, but I'm sure there's people who like the approach you've taken as well
My memory has always been crap, so I want my tools to help, by always providing real help, and saving me from mistakes by rejecting invalid input.
This is also supported by babashka.cli btw. It has :restrict
, :validate
and :coerce
which all throw on unexpected unput.
So I totally get the style of "I just want to make it easy to invoke my existing Clojure functions from the command line" and I think you've nailed that better than tools.deps stuff, and I'm going for a more "I want these commands to look like this" approach.