Fork me on GitHub
#babashka
<
2020-12-13
>
David Pham08:12:29

It is really interesting :) You could use babashka as the cli tool then?

David Pham08:12:57

I am using deps.clj but this would replace it?

borkdude09:12:45

This won't replace it but uses deps.clj under the hood. I haven't really thought about CLI usage but this is a way to invoke clojure from a bb script.

borkdude09:12:08

We could have a bb clojure -Sdeps ... subcommand?

borkdude10:12:55

Pushed:

$ bb clojure
Clojure 1.10.2-alpha2
user=> (+ 1 2 3)
6
user=> ^D

borkdude10:12:03

This will be the first real subcommand I guess

borkdude10:12:27

This would I guess replace the deps.clj project, if people already have babashka installed. @neo2551

borkdude10:12:16

Merged bb clojure and babashka.deps add-deps + clojure to master now.

❤️ 6
David Pham10:12:18

This is really interesting. I think it provides an even better way to enter Clojure world!

David Pham10:12:10

What happens under the hood, if I might asked? Do we have an exact copy of deps.clj behavior?

borkdude10:12:36

Yes. It just invokes the deps.clj main.

David Pham10:12:30

It really helps a lot. I fear updated deps.clj in office

David Pham10:12:47

because I still remember the pain to get the required clojure tools jar from deps.clj

borkdude10:12:48

> I fear updated deps.clj in office could you explain more? this will still download the required clojure tools jar

David Pham10:12:35

In office, we are blocked by a proxy and so the installation process for deps.clj is more invovled, we can't perform http request from terminal. So we have to download the jar manually. It would be beneficial to have a link showing us which dependencies we can download manually and put in the .clojure/.deps folder (I don't remember precisely).

borkdude11:12:21

@neo2551 The newer deps.clj will print this when it can't download the jar:

Could not find /Users/borkdude/.deps.clj/1.10.1.763/ClojureTools/clojure-tools-1.10.1.763.jar
Attempting download from 

borkdude11:12:54

That should be sufficient info to fix it manually

David Pham11:12:45

Thanks a lot!

David Pham11:12:04

I am sorry for bothering you with these silly problems.

borkdude11:12:19

Not at all, it's exactly the pain I'm trying to solve with this

David Pham11:12:05

Babashka and deps.clj were critical for passing the Clojure pill in my team.

David Pham11:12:34

It made installation and trying stuff so much "easier" because now it was reachable without any additional admin rights.

borkdude11:12:47

That's very good to hear

borkdude11:12:59

Pushed docs for babashka.deps/add-deps here: https://book.babashka.org/master.html#_add_deps Will write some docs for the rest

🎉 15
Olical14:12:18

Hey folks 🙂 I was just wondering if anyone is using babashka + nREPL + pretty printing? Not sure if bb's nREPL supports the same pretty printing keys as JVM nREPL :thinking_face:

borkdude14:12:08

@olical Do you mean cider-pprint-eval-expr or something named like that?

borkdude14:12:58

There is a PR here with some open questions: https://github.com/babashka/babashka.nrepl/pull/33

Olical14:12:09

Ohh interesting! Thanks a lot, this is helpful. Was just interested in the state of this concept 🙂 I had someone ask me about it RE Conjure the other day and I just had no idea.

borkdude14:12:38

Feel free to dig in. Still waiting on a reply from Bozhidar but maybe you will have some ideas as well

borkdude16:12:53

So one thing I'm currently wondering about: How can I introduce "sub-commands" like bb clojure -M -e "(+ 1 2 3)" (and possibly also bb uberscript ... etc without conflicting with similarly named scripts. E.g. if there is a file clojure or uberscript (without an extension), this will conflict with the sub-command. Should I just go with: bb --clojure -M -e "(+ 1 2 3)" ?

borkdude16:12:30

Maybe --clojure is good enough and I should just let go of "nicer looking" subcommand idea

lukasz16:12:01

@borkdude bb exec <subcommand> perhaps? (to borrow from ruby's bundler) Although I'm not 100% clear what the sub-commands would do :-)

borkdude16:12:13

exec is then a subcommand itself which doesn't solve the problem I was wondering about :)

lukasz16:12:38

since exec is a posix/bash/etc builtin - unlikely you'll have naming clashes

lukasz16:12:57

as opposed to any other name

borkdude16:12:56

bb exec clojure -M ....
bb clojure -M ...
bb --clojure -M ...
bb exec uberjar -m foo.bar -cp $(clojure -Spath) -ofoo.jar
bb uberjar -m foo.bar -cp ... -o foo.jar
bb --uberjar foo.jar -m foo.bar -cp ...

lukasz16:12:17

I take it back, it looks bad

lukasz16:12:35

--uberjar makes it obvious what's going to happen

borkdude16:12:10

Yeah, and bb --help is pretty clear what is the expected way of passing the args, so keeping the --clojure hyphened style is probably best

borkdude16:12:02

tools like clojure and curl only take - or -- commands, but no subcommands. git and docker always take a subcommand I think

borkdude16:12:31

Also --foo is unlikely to conflict with any file

lukasz16:12:57

I'm afraid the sub-command ship has sailed

borkdude16:12:38

Yeah and I'm alright with that. bb in its simplest use doesn't need a subcommand.

lukasz16:12:40

unless you release a breaking change version

borkdude16:12:50

We can make it non-breaking

borkdude16:12:17

we can prioritize files over the subcommand name but this will be very confusing

lukasz16:12:50

reminds me of nodes require working with dirs or files because it tries to be clever

lukasz16:12:56

and leads to weird issues

borkdude16:12:00

alright, --clojure it is then.

borkdude16:12:34

I really appreciate the feedback from this channel, helping me think into the right direction

borkdude16:12:07

explanation in the help output:

Uberjar:

  --uberjar    <jar>  Similar to --uberscript but creates jar file.

Clojure:

  --clojure [args...] Invokes clojure. Takes same args as the official clojure CLI.

borkdude17:12:06

If anyone wants to try it, there are binary downloads in #babashka_circleci_builds :

$ bb --clojure -M -e "*clojure-version*"
{:major 1, :minor 10, :incremental 2, :qualifier "alpha2"}

👍 3
borkdude19:12:54

One of the last things I want to consider for now for babashka.deps / tools.deps related usage within bb: Setting the default classpath for a bb "project" 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):
(require '[babashka.deps :as deps])
(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

borkdude20:12:45

I think we have enough to get started with. Just published 0.2.5: https://github.com/borkdude/babashka/blob/master/CHANGELOG.md#v025

dharrigan20:12:03

arch updated 🙂

🎉 3
nate20:12:32

This is awesome. Looking forward to playing with it.

borkdude20:12:18

Thanks for the useful feedback. Hope we got it right the first time ;)

nate20:12:27

Crazy idea: is there a possible future where bb doesn't even need Java to add deps? Would this mean we have to get the entire t.d.a. stuff to graal compile?

borkdude20:12:06

@nate I've been experimenting with that: https://github.com/borkdude/tools-deps-native-experiment but I haven't quite figured it out yet.

borkdude20:12:49

The README is out of date. But you'll likely run into a different issue

borkdude20:12:54

Tried again but doesn't really finish compiling...

nate21:12:00

Ah cool. Everywhere I use bb, I have the jvm, and I suspect that's the common situation.

borkdude21:12:11

Yeah. babashka.deps assumes a JVM. You don't have to use it, but it's convenient. And due to caching, it's fast when your deps are already downloaded and the classpath has been calculated before.