This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-09-07
Channels
- # announcements (4)
- # babashka (59)
- # beginners (26)
- # calva (34)
- # clj-kondo (3)
- # cljs-dev (1)
- # clojure (77)
- # clojure-austin (4)
- # clojure-europe (20)
- # clojure-nl (2)
- # clojure-norway (11)
- # clojure-spec (3)
- # clojure-uk (4)
- # clojurescript (103)
- # community-development (2)
- # cursive (15)
- # datalevin (12)
- # datascript (38)
- # datomic (1)
- # deps-new (2)
- # events (3)
- # figwheel-main (6)
- # fulcro (9)
- # honeysql (12)
- # jobs (4)
- # juxt (18)
- # kaocha (19)
- # lsp (42)
- # missionary (2)
- # pathom (14)
- # polylith (6)
- # portal (6)
- # reagent (8)
- # reitit (4)
- # releases (2)
- # shadow-cljs (17)
- # testing (1)
- # tools-deps (50)
- # vim (46)
- # xtdb (12)
Does anyone have any ideas on how I could generate documentation pages for a babashka pod... bear with me while I explain...
the source from this directory is embedded into the compiling source with macros, so that it can be injected into the babashka runtime when the the pod is describe
d
if its in the classpath, it cant compile. It fails with java.lang.ClassNotFoundException: babashka.pods
(because I use the async invocation method for some functions, calling babashka.pods directly)
No it somes time to generate some docs, I turn to codox. But codox looks for its source on the classpath. So if src/bb
is not on the classpath, it cant find the files. And if it is on the classpath, it wont compile, thus wont generate the docs.
Has anyone done something like this before? Generated documentation for a library that is outside the clojure compilation space?
I could preprocess the source code, remove the offending vars, and then codox that. thats one solution.
I'm just checking with the brains trust to see if anyone has done anything like this before
OK. I got something working by copying the source to a temp directory and quoting the offending vars so they dont get evaluated in compilation. Now codox is making docs! yay!
Another idea if you want to use codox: create fake source code or so programmatically? You might be able to use clj-easy stub
So I guess clojure.main/with-bindings
is not exposed because it is a macro? (https://github.com/babashka/babashka/blob/c97fb958dc7bb19dbb8dcd1947e1e6808c37df6b/src/babashka/impl/clojure/main.clj#L28-L51)
@flowthing it's not exposed because I didn't need to expose it yet and nobody asked for it yet
@flowthing but we could certainly expose it
@flowthing now we're at it, let me also check this source-path thing
should it just be added as a "dummy" thing, so you don't have to write the reader conditional?
in that case, I think writing the reader conditional might be better than adding it since adding it would maybe create the wrong expectations
Well, I wouldn’t mind that, at least. But I won’t feel bad about writing the reader conditional, either, now that I now I can use *file*
to get the file name in the exception message.
It’s just clojure.main/ex-triage, clojure.main/ex-str, clojure.main/repl-exception, clojure.main/repl-caught, clojure.main/skip-whitespace, and clojure.lang.Compiler/load left for my use case. 🙂 They’re mostly nice-to-have, but do you have any feelings on whether it makes sense to put any effort into them?
I'm not sure how well they map on the SCI side of things. clojure.lang.Compiler/load
won't work since SCI isn't a compiler
Looking at the clojure.main ones, some of them do have a dependency to clojure.spec.
I want to build spec into bb at one point (I have a branch of that). Right now you can run spec with bb but as a completely optional library that is not tied to anything built-in
I think I can vendor in the bits from clojure.main
I need for now and return to them if necessary. Once again, many thanks for this! I’ll start working on polishing Tutkain’s improved Babashka support into a shippable state. 🙂
Hi, if I have a top/bb.edn
file and a top/subdir/bb.edn
, is it possible to invoke a top/subdir/bb.edn
task from within a top/bb.edn
task? e.g. a solution would be to (babashka.process/shell {:dir "subdir"} "bb subtask")
from within the top/bb.edn
, but this would invoke a second bb process which is wasteful, thanks
@U012BL6D9GE this isn't possible, you could use babashka.process/exec
if you want to "exec", i.e. replace the current process with a new bb instance.
There is a discussion with some workarounds/ideas for this over https://github.com/babashka/babashka/discussions/1044
thanks @U04V15CAJ, it would have certainly been a very feature to have. Do you happen to know if there is a way to get the pat to the currently running bb executable, so I'm sure to invoke the same bb exec with shell
rather than the one found in PATH?
*command-line-args*
doesn't appear to include the name of the running exec, as it is customary with argv
in c like languages
yes:
$ bb -e '(.get (.command (.info (java.lang.ProcessHandle/current))))'
"/Users/borkdude/dev/babashka/bb"
It is kind of complicated to implement what you asked for since bb would have to take into account deps and tasks from various places, merge them, etc. I fear that this will be a mess