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

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

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

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

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.

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

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

(if all else fails)

of course the integrated experience is much nicer

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

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

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

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

What will the classpath look like?

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?

@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.

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

lib? ;)

domain?

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