Fork me on GitHub

Hey, folks. Probably a dumb question but here goes: How can I import a local file when using bb? Say file 1 is lox.clj with (ns lox.core) and file 2 is utils.clj with (ns lox.utils)? Located together in the same folder. How can I import lox.utils to use functions defined in that namespace?

Martynas Maciulevičius07:02:03

lein classpath > .classpath
bb -cp $(cat .classpath) -m "your main namespace"


@UTT4YNYNS I recommend creating a bb.edn file with {:paths ["."]}

👍 1

Then you can have the following structure:

$project/bb.edn: {:paths ["."]}
$project/foo.clj: ...
$project/bar.clj: (require 'foo)


A lot of times you will put the sources under script or src-bb or whatever, then your bb.edn will look like {:paths ["src-bb"]}} for example

❤️ 1

Perfect! Thank you


Hmm this isn't working for some reason. I'm still getting "Could not resolve symbol"


@UTT4YNYNS can you try to make a .clj-kondo director in the e1 directory and make sure you open VSCode also in that directory, then restart the editor and also make sure to edit a file


It worked for me locally when I did this.


I'm using emacs


I don't really have a folder structure atm but I'll look into it


The test folder is just source samples for the language I'm working on parsing.


Oh sorry, I'm completely mixing up issues here


I thought this issue was about .clj-kondo. Different problem and different person :)


No worries! The fact that you're actively helping folks is insane and very kind. Where can I donate/support you and your efforts? One day I'd really like to help out with some open source work as well. Right now I'm just a super noob at clojure stuff so I don't have a ton of value to add.


what is in main.clj? are you requiring utils from there?


you can support via github sponsors or opencollective if you'd like


^ Yes that is basically the problem I'm having. main.clj is the main thing, utils is some extra functions I moved to try and keep main clean. I just want to require utils and use functions from within it


and what does the namespace form look like?


I don't have any namespace forms atm. I removed them when I was trying random things to get it working


ok, you will need a namespace form that reflects the filename. in main.clj you have to write (ns main) - the same for utils.clj -> (ns utils)


Ah okay


Do I have to move the require section to the namespace form in main? as in (ns main (:require ...))?


Currently I have this and I'm still getting the "Could not resolve symbol" error.

(ns main)

(require '[clojure.string :as str]
         '[utils :as u])


Nevermind! It's working. I'm just an idiot.


Thank you for your patience and help


you don't have to, this should work. good :)


@UTT4YNYNS thanks a lot for sponsoring!

👍 1
Martynas Maciulevičius07:02:08

Hey. Is there lein in this docker container? I can't find it. It's written that it contains it in the FROM image but it's not in the $PATH.


No, its a multistage build and for the final one we just have the bb binary in an ubuntu image

Martynas Maciulevičius07:02:24

Yeaah... I figured it could be the case but then how do I get a bb image with lein...?


you need to extend your image using FROM babashka/babashka:0.7.4 or something


then install lein jvm etc


its by design that the bb image is as lean as possible.

Martynas Maciulevičius07:02:01

But then why would I care to use that container and instead not install bb and lein from package manager from somewhere else... If I install java I might as well be full author of the container... Hm.


either works. the idea here is bb is an orthogonal runtime to the JVM. if you need both you need to set it up that way. not sure if we'd wanna ship both bb and the JVM in an image, as most use cases of bb is not to use the JVM

Martynas Maciulevičius08:02:27

Yes. That makes sense.


we did not have a need to ship the JVM too til now from the users, let us know if theres some strong requirement, we can think about it 🙂

Martynas Maciulevičius08:02:35

I was trying to create an image for testing. So that developers would be able to download it and run some commands. That's pretty much it.


Right, i guess building it yourself and letting the container runtime cache it locally would work for most cases for now. But in some recent commits on bb i think @U06FS3DLH has a plan to have bb images as part of the clojure we on some parts of it. maybe that has lein+bb? maybe he can confirm here?


Once your dependencies are in the images, you probably don't need lein in the image anymore. It's only for downloading dependencies but for running bb doesn't need a JVM or lein or deps.edn, etc. For startup time you want to avoid those basically.

Martynas Maciulevičius08:02:59

This is my container:

FROM clojure:openjdk-11-lein-buster

RUN curl -sLO  && chmod +x install && ./install


Yeah, if you need both, I think that's good / pragmatic. Installing bb is really fast.


Yeah I was kind of waiting to see if there was demand for that beyond the babashka/babashka image. Sounds like maybe there is?

Martynas Maciulevičius19:02:09

If it's two lines then it can be added to readme 😄


Yeah, I think the use case "I want control over my image otherwise, but I just want to run bb scripts too" is quite common!

sheluchin15:02:44;cid=CLX41ASCS I see conditional dependencies have been discussed before. Was anything like this ever implemented?


All good, not a big deal.. just wanted to see if maybe it was missed in the docs. Thanks!

👍 1

it appears babashka 0.7.4 is passing a string arg to one of my pods as ascii rather than utf8. it was how I was decoding it (`(String. bytes)` vs. (String bytes "UTF-8")). or am I doing something wrong? I'm seeing ü turn into ?


is this specific for 0.7.4?


and what pod data format is this, json, transit, edn?


no, just what I'm testing w/ now. edn


might be how I'm decoding it on my end


going to try changing (String. bytes) to (String. bytes "UTF-8") in my pod and see what that does


it defaults to "platform charset" and this is running in an AWS lambda, so kind of an odd platform


yep, that fixed it. all on my end!


good to hear!