Fork me on GitHub
#babashka
<
2021-08-03
>
borkdude12:08:21

Very nice! > There’s still more to do on the Babashka support, in particular this release doesn’t do anything at all with bb.edn. So if you’re adding extra dependencies via that those won’t work for the moment, and there’s no task running support yet either. Note that print-deps will also output the deps in bb.edn

cfleming12:08:18

Oh, interesting. Does that require bb to be run in the directory containing bb.edn? I assume so.

cfleming12:08:49

Currently a project-wide lib is created, but I actually think that’s not the right approach, especially given that information.

borkdude12:08:49

yes, bb.edn is picked up from the current working dir

cfleming12:08:34

Ok. The only time anyone would see weirdness right now is if they have a large project with multiple bb.edn files and different dependencies in each one.

borkdude12:08:35

but hey, this is already a major improvement, let's wait for the feedback

borkdude13:08:03

What people can also do is using print-deps manually, create a deps.edn, develop as if normally on the JVM and then run the script with bb again when ready

borkdude13:08:47

(if all else fails)

borkdude13:08:58

of course the integrated experience is much nicer

borkdude13:08:17

clojure-lsp will also release a version today which leverages this new feature for better analysis

Mikey OBrien14:08:28

Is it possible for tasks to be discoverable from within project subdirectories?

escherize19:08:19

I’m doing something similar. heres my script

#!/usr/bin/env bb

(require '[clojure.java.shell :refer [sh]]
         '[clojure.string :as str]
         '[babashka.fs :as fs]
         '[babashka.process :as p :refer [process check]])

(defn find-up [target]
  (let [here (:out (sh "pwd"))]
    (loop [parents (iterate fs/parent here)]
      (if-let [dir (first parents)]
        (let [dir-str (str (str/trim (str dir)) "/bin")
              local-files (set (str/split-lines (:out (sh "ls" dir-str))))]
          (if (contains? local-files target)
            dir-str
            (recur (rest parents))))
        (throw (ex-info "Not found." {:target-file target}))))))

(let [cmd (into ["bb"] (or *command-line-args* ["tasks"]))
      p (process cmd {:dir (find-up "bb.edn")
                  :in :inherit})]

  (when ((into {} System/getenv) "DEBUG")
    (println "==================================================")
    (println "cmd:" (pr-str cmd))
    (println "dir:" (find-up "bb.edn"))
    (println "=================================================="))

  (binding [*in* (io/reader (:out p))]
    (loop []
      (when-let [x (read-line)]
        (println x)
        (recur)))))

👍 2
escherize19:08:50

I put that into a file called b

🙌 3
borkdude14:08:16

@hmobrienv Currently bb only takes into account the bb.edn in the current working dir

smessica08:08:41

Support for explicit bb.edn file would allow both to run the tasks from anywhere and also to have different sets of tasks like admin-tasks.edn and dev-tasks.edn for different usages on the project. bb --conf ~/prj1/bb.edn run test

borkdude08:08:29

@U1LG6HNMT The question here is: should --conf ... take into account the relative sources the current working directory, or from the config directory

borkdude08:08:38

What will the classpath look like?

smessica08:08:59

I think that the conf file might be the pivot. It will be relative to its location. I guess that explicit root would also be useful, maybe on the bb.edn to be able to override the default of conf file location. would that make sense?

borkdude09:08:47

@U1LG6HNMT I think there is a discussion about this exact topic here: https://github.com/babashka/babashka/discussions/869 Could you please leave your feedback there? Then we can collect all the data to make good decisions.

borkdude14:08:10

@hmobrienv You can invoke a command in a subdirectory from the top level bb.edn though, if that is your use case

borkdude14:08:25

(shell {:dir "subdir"} "do stuff")

Mikey OBrien15:08:58

I do a lot of work with Terraform so i’m rarely in project roots but have some complicated manual processes to build dependencies i’d like reachable anywhere. I suppose I can go the invoking commands in a subdirectory route. Thanks!

borkdude15:08:24

I'm considering forking tools.deps.alpha and ripping everything out but gitlibs and then see if that can be included in bb itself. That code should be relatively thin. And then the trade-off will be: use only (transitive) git libs and don't need Java for deps (only a git install), or use clojars/maven libs and then "pay" some Java startup time... I will then also attempt to port the git libs stuff to .cljc so it can be used on node (for #nbb)

💯 5
agu monkey17:08:39

I tried building babashka 0.5.1 (using the website tutorial) and the resulting jar takes 7 seconds to boot, did I miss something ?

Mikey OBrien17:08:24

Is there an option to suppress task output?

borkdude20:08:22

Yes, you can direct to /dev/null for example using (shell {:out "/dev/null"} ...)

borkdude17:08:21

@agu.monkey The jar is not yet the binary

agu monkey18:08:05

ok after letting my cpu overheat I finally get the snappiest ./bb thanks a ton (and massive congrats for assembling babashka, quite a gem)

richiardiandrea19:08:32

Naming is hard, how do you call the folder where all the "shareable"/"model" code resides? I am thinking of extrapolating things for babashka scripts to use that are not related to database and all that. These are the actual domain pure functions...kind of like having .cljc files for ClojureScript

borkdude20:08:33

domain?

❤️ 3
richiardiandrea20:08:07

yeah I was thinking about domain - I just don't want to go for lib or shared cause they give small info to the reader