Default classpath for bb "project"

[borkdude]

Setting the default classpath for a bb project was "traditionally" done using $(clojure -Spath ...).

This isn't very nice:
$ bb --classpath $(bb --clojure -Spath -Sdeps "{:deps {medley/medley {:mvn/version \"1.3.0\"}}}")

We can already do this from within a file (on master):

(deps/add-deps '{:deps {medley/medley {:mvn/version "1.3.0"}}})
...

Options:

• automatically read deps.edn if present. Have a --deps-aliases argument to modify the classpath using aliases. Not my favorite option, since it will change current behavior and typically you will have a different set of deps for bb and clj when bb is used for scripting inside a JVM project.
• separate babashka.edn with :deps and :paths. Set classpath when present. Maybe also support command line aliases, although I'm not sure if someone is going to different sets of deps for one script.
• Maybe leave this out for now, since programmatic setting of the classpath using babashka.deps and babashka.classpath is sufficient

This is a continuation of #473

[borkdude]

Here is an idea from a conversation I just had:

Instead of a config file we could just have a side-effecting setup script or function.

.babashka/setup.clj

or

babashka_preloads.clj

or a

(defn -setup [_]
  ...
  )

function at the bottom of your script where you do the loading of the pods, setting of the classpath, adding of deps with babashka.deps, etc, so your ns form can be clean looking.

pez:calva: 14 minutes ago
I just prefer (:require [script.foo :refer [bar]]) ¯_(ツ)_/¯
In the ns form.

borkdude 8 minutes ago
I am considering a .babashka/config.edn for projects where you can set the project classpath for example.
But it is pretty normal in scripts to have multiple require forms, for setting the classpath, adding clojure deps (via babashka.deps), loading pods, ... (edited)
Maybe there should be a .babashka/setup.clj where these side effects can occur
instead of a config file

[onetom]

Having NS declarations in an NS form also helps tooling, which does static analysis, like Cursive.
The experiments I've done so far I did in Cursive and I've added NS forms just so I can utilize Cursive's auto-completion and code navigation capabilities.

Also, why call these files babashka*? The executable itself has already been named - very concisely and elegantly - just bb. I think it would make a lot of sense to just stick to that convention. It's not very likely to collide with anything else. That's just a gut feeling though, so pls contest the idea...

The other reason for keeping these things concise is to stay aligned with the core goal of Babashka: "Babashka is a native Clojure interpreter for scripting". To me scripting also carries the meaning of quick experimentation, where concision helps a lot. We can see the results in action if we look at the GNU coreutils. I think conciseness worked out quite well there.

[borkdude]

@onetom About the naming: yes, we can have bb.edn or bb.clj or .bb/setup.clj as a setup file.

[borkdude]

Went with option 2 on master now:

• separate babashka.edn with :deps and :paths. Set classpath when present.

Not yet supported:

Maybe also support command line aliases, although I'm not sure if someone is going to different sets of deps for one script.