I have source on the classpath src/clj. And this builds the actual pod.

but I also have another source directory src/bb which is not on the classpath

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?

Any other docgen tools?

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!

Have you tried #quickdoc ?

no. I'll have a look

hey cool. just generates markdown 👍

will have a use for this somewhere.

Ive got the codox docs looking pretty nice..

Another idea if you want to use codox: create fake source code or so programmatically? You might be able to use clj-easy stub

it turned out to be pretty easy, cause there was only one offending place

https://github.com/epiccastle/bbssh/blob/main/Makefile#L89

@flowthing now we're at it, let me also check this source-path thing

Many thanks once again!

I'm not so sure how things are affected by source-path

Yeah, it’s a bit weird.

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.

Yes, I totally agree. It might just be confusing more than anything else.

OK, then I'll close the issue

:thumbsup:

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

Yeah, I figured that might be a no-go.

Looking at the clojure.main ones, some of them do have a dependency to clojure.spec.

That makes things a bit difficult, I think.

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

Right. :thumbsup:

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. 🙂

Awesome. Happy to retweet something, if you're doing that kind of thing.

I don't use Twitter, but thanks. 🙂

If they are defined in a file, yes

Ah, I see. So core vars won’t have it. ✅

We can maybe continue in #babashka-sci-dev for the more technical details

@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

there is also the "current working directory" problem

so I think doing this in user space would be best for now

I think I can see the difficulty managing the same dependency but with different version numbers coming from subprojects

I'm fine with user space as it is at the moment