Fork me on GitHub
#babashka
<
2023-04-01
>
keychera11:04:31

question about babashka pods running on the JVM, why does this

(pods/load-pod 'retrogradeorbit/bootleg "0.1.9")
(require '[pod.retrogradeorbit.hickory.select :as s])
prints out warning below?
WARNING: class already refers to: #'clojure.core/class in namespace: pod.retrogradeorbit.hickory.select, being replaced by: #'pod.retrogradeorbit.hickory.select/class
WARNING: and already refers to: #'clojure.core/and in namespace: pod.retrogradeorbit.hickory.select, being replaced by: #'pod.retrogradeorbit.hickory.select/and
WARNING: or already refers to: #'clojure.core/or in namespace: pod.retrogradeorbit.hickory.select, being replaced by: #'pod.retrogradeorbit.hickory.select/or
WARNING: not already refers to: #'clojure.core/not in namespace: pod.retrogradeorbit.hickory.select, being replaced by: #'pod.retrogradeorbit.hickory.select/not
I thought it’s already not using :refer :all ? any way I can turn them off? so far nothing breaks, it’s just that this warning keeps showing that’s kinda get annoying after some time

borkdude11:04:43

It's probably due to how pods in the JVM work. It defines vars using intern.

user=> (intern 'user 'and 1)
WARNING: and already refers to: #'clojure.core/and in namespace: user, being replaced by: #'user/and
#'user/and

borkdude11:04:36

I'm not sure if there's a way to avoid these warnings, re-binding *out* and *err* don't seem to work. Perhaps calling ns-unmap first would work

borkdude11:04:58

Ah yes:

user=> (do (ns-unmap 'user 'dec) (intern 'user 'dec 1))
#'user/dec

borkdude11:04:22

Issue + PR at babashka pods welcome (PR is optional, but only if you want)

keychera11:04:30

ah, thanks for the explanation, I’ll make the issue first I guess. gonna do that later today

borkdude11:04:41

thanks a lot!

Mandimby Raveloarinjaka13:04:01

I have a question regarding how dependencies are managed between bb.edn and deps.edn. In one of my project I mix scripts runnable by babashka and scripts I run using clj. In order to manage the dependencies I use a single deps.edn and bb.edn references it using {:local/root "."} as described in the book. I added aero in the the deps.edn but I noticed that I could not require it in a babashka scripts unless I override the class path "-cp (clj -Spath)" or I declare the dependency in the bb.edn. Do I miss something?

borkdude13:04:53

@U805L34UX can you paste your bb.edn and deps.edn below? A common mistake is to not use a unique name for the local/root

Mandimby Raveloarinjaka14:04:47

actually I setup a sample repository and it works perfectly (https://github.com/mraveloarinjaka/bb_and_deps). I am going to see what is not working on the faulty project on Monday (at work). Thank you for your prompt reply.

borkdude15:04:07

@U805L34UX This is the problem:

{:deps {local/deps {:local/root "."}}}
Don't use the name local/deps but use the unique name of your project, that people also would use when using your library as a dependency

👍 2
borkdude15:04:21

if you re-use this local/deps name across projects, you will get caching issues and the wrong dependency

Mandimby Raveloarinjaka15:04:24

across projects on the same machine?

Mandimby Raveloarinjaka15:04:29

I thought that dependencies were cached inside the project directory

borkdude15:04:36

not for bb scripts

Mandimby Raveloarinjaka15:04:46

ok so that is the explanation

Mandimby Raveloarinjaka15:04:34

I guess that is why you suggest to use a unique nickname in the book. Anyway thanks a lot for your help

borkdude15:04:48

yes, that is indeed why it's suggested