Fork me on GitHub
#babashka
<
2021-01-26
>
jaide01:01:28

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?

jaide02:01:28

I suppose that’s what pods do?

bherrmann02:01:54

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

jaide06:01:21

Thanks! I’ll have to experiment with that.

jaide15:01:52

Thanks will read this thoroughly

jaide06:01:54

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
Any thoughts how I can compile the pod to not require GLIBC_2.14?

borkdude08:01:37

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

jaide15:01:16

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

lispyclouds06:01:46

@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

jaide15:01:49

Thanks I think I was missing the static flag!

jaide22:01:45

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

jaide22:01:01

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

borkdude22:01:28

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

borkdude22:01:51

(PR always welcome)

borkdude22:01:11

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])

borkdude22:01:41

ah let me just update it right now

borkdude22:01:42

@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

borkdude22:01:54

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

jaide22:01:07

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

borkdude22:01:53

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

borkdude23:01:21

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

jaide23:01:34

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

borkdude23:01:03

you can run docker containers there?

borkdude23:01:31

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

jaide23:01:33

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

borkdude23:01:33

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

borkdude23:01:48

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

borkdude23:01:16

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

borkdude23:01:33

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

borkdude23:01:29

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

jaide23:01:39

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

borkdude23:01:13

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

borkdude23:01:43

assuming it has no dependencies

jaide23:01:28

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.

jaide23:01:57

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?

borkdude23:01:38

We can publish a static release if that helps

jaide23:01:21

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

borkdude23:01:55

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

borkdude23:01:17

I'm off now, getting late. PR welcome

jaide23:01:25

Cool, I can handle that. Thanks again!