@U09N5N31T it depends. can you provide a full repro?

deftype in general has only limited support in babashka. it's probably better to avoid it and write your own close! function

I think something is wrong with our code — looks like it expects a close method in a protocol to implement a .close java method and that is probably not correct

In that case you could call the protocol method without interop:

(protocol-ns/close ...)

@U09N5N31T did you manage to figure it out?

@U04V15CAJ yes we found the cause and adopted a workaround. Using the protocol clojure function instead of the interop method, as you suggested, works: https://git.sr.ht/~rwv/cljs-exif-reader/commit/ee3d94da53133f58b581f09964e84134721703eb

Thanks!

@U09N5N31T are you planning to announce this lib somewhere? else I can make a shout-out of it here in the bb channel or elsewhere

A shoutout would be nice! you can link to here: https://git.sr.ht/~rwv/cljs-exif-reader

@U45T93RA6 "Can I lint", what does this mean?

the linter returns 0 iff the .clj file is bb-compatible

ah, like that. no, this doesn't exist yet, but there is or was an issue for it in clj-kondo :)

Good to know!

The best way is to just try it out and see (and ask questions here)

My bandwidth is fairly limited to try things out, unfortunately. As hinted I'm not primarily a bb user. Although I could follow something like a brief doc guide (or eventually linter) on how to keep compat (e.g. avoid this construct or lib) This is merely a suggestion though - currently I don't have a pressing scenario

we have this https://github.com/babashka/babashka#differences-with-clojure as of now

Those docs are a bit out of date though

and the know https://github.com/babashka/babashka/blob/master/doc/projects.md of things that work

also https://babashka.org/toolbox/

to ensure compatibility when writing libs, I usually use the cognitect test runner and run tests for both jvm and bb

> Those docs are a bit out of date though yes not sure whats the reference for the differences are now. the book is in a similar state i think as well?

we should link to the book from the README and then update the book

but in summary: to ensure compatibility: it's best to run the tests you've already written for JVM Clojure and run them with bb and run those tests in CI.

I also want this! (I think I've asked about it before). I would prefer to only write babashka-compatible clojure. So I'd want to opt in globally so that my linter for clojure files warns me each time I'm doing something that won't work in babashka.

What is not babashka compatible is constantly in flux (going towards clj compatibility, not the reverse) so maintaining that linter is like maintaining the docs: it will always go stale. Running tests is the best remedy against that

Just loading the code in bb (executing the top level defn, etc) will already tell you a lot: references to Java libraries that aren't in bb, deftype with Java interfaces, etc

As a rule of thumb, it's best to stick to normal functions and data structures, avoid external Java libraries, avoid doing interop in the name of better performance (it works, but it's less performant in bb), just use the core functions, avoid custom data structures/types (it can be done, but it is not fully supported and less performant)

So a CI smoke test that just tries to load it all in a babashka interpreter might be a "good enough" solution? Or a "unit test" that does the same?

unit tests > smoke tests, of course

if you're running tests in CI with the JVM, run them with bb as well

it's a legit approach though, especially if I don't have tests for my scripts

here is an example: https://github.com/lispyclouds/contajners/blob/main/.github/workflows/ci.yml#L34-L38

@U45T93RA6 if you don't have tests for your script, it's easy enough to find out if it works in bb by just running it with bb instead of clojure?

then we're back at the original point i.e. I just want to keep the script for others to possibly run with with bb throwing a few linters at a script is easier (and less side-effectful) than running it

yes, but if the linters don't complain it's still not a guarantee that it will work, it's only a good initial indication (which may go stale)

even if it's a "code loader" instead of a linter? ...anyway, I was just testing the waters, I expect nothing 😇

@U45T93RA6 it depends on how you set up your script. if you set it up as something that doesn't cause top level side effects, you can use bb as the code loader to probe incompatibilities

"linter as dockerized/isolated code loader smoke test" is an interesting idea

well, there's bb docker images, so have at it ;)

definitely possible to solve in userspace without changing babashka or clj-kondo 🙂

I guess a linter would be interesting. Like, "hey, what you are doing here, my friend Lee, definitely won't work with bb". But to claim bb compatibility for a lib, I'd always run the lib test suite under babashka itself.