Clojurians Log v2

If this is covered in the docs I’ll look harder but didn’t see it on first pass: Is there a way to break up scripts into separate files in bb and require them?

I suppose that’s what pods do?

You can use add-classpath to tell bb to search other places for your ns

See https://book.babashka.org/#libraries

Thanks! I’ll have to experiment with that.

I used the dockerfile from the babashka repo to compile the postgresql pod. I copied the generated binary to my server in the .babashka/pods/repository/org.babashka/postgresql/0.0.1 directory then tried to run the postgresql sample code:

.babashka/pods/repository/org.babashka/postgresql/0.0.1/pod-babashka-postgresql: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /home1/[redacted]/.babashka/pods/repository/org.babashka/postgresql/0.0.1/pod-babashka-postgresql)
----- Error --------------------------------------------------------------------
Type:     java.io.IOException
Message:  Stream closed
Location: /home1/[redacted]/public_html/clj-test/cgi-bin/./test.clj:4:1

----- Context ------------------------------------------------------------------
1: #!/home1/[redacted]/public_html/clj-test/bb
2:
3: (require '[babashka.pods :as pods])
4: (pods/load-pod 'org.babashka/postgresql "0.0.1")
   ^--- Stream closed
5: (require '[pod.babashka.postgresql :as pg])


----- Stack trace --------------------------------------------------------------
user - /home1/[redacted]/public_html/clj-test/cgi-bin/./test.clj:4:1

@jayzawrotny you could try compiling the pod statically. https://www.graalvm.org/reference-manual/native-image/StaticImages/ Maybe have the uberjar and then use native-image --static ...? Thats how we build the babashka static binary

The static steps here might help: https://github.com/babashka/babashka/blob/master/.circleci/config.yml#L142

@holyjak @borkdude Yeah I think this looks good. I’m using a custom tool and credential_process to assume credentials. I could try converting that to Bashbashka at some point

Also see: https://book.babashka.org/#_classpath https://book.babashka.org/#babashka_classpath https://book.babashka.org/#babashkadeps

Yes, you need to use the --static flag to compile it to a static binary on linux

Oh I missed that flag sorry about that. Thanks again!

Thanks will read this thoroughly

Thanks I think I was missing the static flag!

https://github.com/babashka/babashka/blob/master/script/compile#L71 this section is helping me a lot too

That worked! Thanks again for all the help borkdude and lispyclouds.

What’s the best way to use honeysql? Is it still what’s recommended here? https://github.com/babashka/babashka-sql-pods/#honeysql

@jayzawrotny This is now the more easy way: https://github.com/babashka/pod-babashka-sqlite3#honeysql We should update the sql-pods docs

(PR always welcome)

So:

(ns honeysql-script
  (:require [babashka.deps :as deps]
            [babashka.pods :as pods]))

;; Load HoneySQL from Clojars:
(deps/add-deps '{:deps {honeysql/honeysql {:mvn/version "1.0.444"}}})

(require '[honeysql.core :as sql]
         '[honeysql.helpers :as helpers])

ah let me just update it right now

done

@jayzawrotny Note that using babashka.deps requires a JVM and is only fast when the classpath is cached. I'm not sure if that's available on your shared host

But you can build an uberjar with babashka as well and upload that

So that means building a static babashka + honeysql as a static binary and babashka-sql-pod as a static binary?

To build an uberjar, add honeysql to a deps.edn and then bb -cp "$(clojure -Spath)" -m your-script.main --uberjar foo.jar You don't need to change babashka itself

this is just to prevent needing a JVM in the shared host

And I should do that in the babashka build docker container then upload to my shared host?

you can run docker containers there?

No

oh, I see, no you don't need to build babashka itself to be able to use it with source libraries

I just meant build it in your linux container for babashka on my local

Ohhh

as long as you manage to get the source on the classpath, it's fine. babashka.deps can manage this for you (through tools.deps on the JVM) or you can do it yourself in some other way

e.g. an uberjar is a way to package the source in a standalone file

well "standalone". you still need bb to execute it: bb foo.jar

I guess you can even package the pod in resources and then spit it out on the shared host using io/copy the first time

but you will also need to copy bb itself there, so maybe one extra binary file to copy isn't that bad

@jayzawrotny https://book.babashka.org/#_uberjar

I’ll have to try that tonight. Thanks for all the help, I really appreciate it!

No problem. You can also git clone honeysql and then add the source to the classpath using babashka.classpath. This is another way without the JVM

assuming it has no dependencies

I’m thinking getting some third-party libs like honeysql in there is the last major problem that needs to be worked out and tested before at least writing a guide\tutorial, then with that super uberjar that might streamline the process.

One thought I haven’t decided yet on though is if I should make a PR to add a dockerfile to the sql pod (and eventually other pods) or if I should create a template repo with some scripts and presets to help others get started?

We can publish a static release if that helps

Oh yes! That would reduce some steps for people. How can I help with that?

We generate a CircleCI config here: https://github.com/babashka/babashka-sql-pods/blob/master/script/generate_circleci.clj You would just have to add one extra job that is the same as the other linux one but with the --static, which you could do using an environment variable

I'm off now, getting late. PR welcome

Cool, I can handle that. Thanks again!