Fork me on GitHub
#babashka
<
2023-02-02
>
pez07:02:33

Can I restore the 1.1.170 behaviour of printing the script results in some backward compatible way? 1.1.170 doesn't like the --prn option.

borkdude07:02:16

How are you using it? It should be used as a global option, ie one of the first things you pass

pez07:02:07

I tried with a shabang on my script, like so:

#!/usr/bin/env -S bb --prn -cp ./bin
Works fine with 171. With 170 I get
Message:  File does not exist: --prn

borkdude07:02:40

Ah shame, I guess it’s not compatible then

borkdude07:02:00

Why not use explicit printing?

pez07:02:44

My script blows up in 171 (for reasons I am investigating) and it is completely silent. With --prn the error and stack trace is printed.

borkdude07:02:59

That sounds like a try/catch which then returns the exception as a value which then gets printed

pez07:02:24

Hmmm, it blows up silently with or without --prn , (it's a shell-out). I added an explicit throw when I get non-zero exit value. Maybe that gets returned...

borkdude07:02:26

If you use ‘process/shell’ it should throw

pez07:02:26

I'm using java/shell. It's an old script. Has been ticking along since very long and suddenly stopped doing anything some week ago.

pez07:02:11

I can rewrite using process/shell. But I want to understand what changed.

borkdude07:02:14

—prn does nothing else than print the last value like the old version did. It has no impact on error reporting. If you use an explicit ‘prn’ on the last value then behaviour should be 100% the same in both versions

pez07:02:09

Thanks. I'll do that for now.

pesterhazy10:02:31

wow, I didn't know about the env -S trick - is that to support multiple args?

borkdude11:02:33

That isn’t a cross platform feature

pesterhazy11:02:16

I guess env -S works on macOS and Linux, isn't that cross-platform enough?

2
borkdude12:02:40

I remember something being not cross-platform about it, but I'd have to look it up

borkdude12:02:50

but I guess if nobody complains and it works, keep using it :)

borkdude14:02:16

It seems it started working on linux a few years ago, but it wasn't cross platform before. https://unix.stackexchange.com/a/477651/28294

oly11:02:12

I am using bb tasks and trying to pull in a github repo, how ever I am getting Error building classpath. Unable to clone, and fatal: could not read Username for 'https://github.com': terminal prompts disabled. the only thing I notice is it says username and not organisation but perhaps they are treated the same. any idea's on what may cause this ?

elken11:02:03

Looks like an auth issue

☝️ 2
oly11:02:49

it is a private repo, I am running it locally so would have expected it to use my auth.

oly11:02:17

I can pull and push to the repo, or is it a case of you can only use public repos

elken11:02:31

Well that's what the error means, without any idea of what you're doing code-wise we can't offer any more help 🙂

oly11:02:06

{:paths ["bb"]
 :deps {io.github.organisation/build-tools {:git/sha "mysha"}}
 :tasks
 {}} 
basically that, then running bb tasks

elken11:02:05

Try :deps {name/build-tools {:git/url "url" :sha "mysha"}}

oly11:02:26

cheers, that does indeed seem to work, which makes me wonder what the differece is

elken11:02:46

The difference is that's not how you define a git dep 😉 Probably couldn't infer the repo from the name

pavlosmelissinos11:02:14

Yeah, io.github.* should work :thinking_face:

oly11:02:15

which does not use :git/url

pavlosmelissinos11:02:52

Maybe babashka doesn't support it?

elken11:02:17

Yeah that's a clojure guide

oly11:02:17

perhaps one uses https as i used the git link in the url,

oly11:02:33

fair enough I did look in the babashka book for an example, it works now so thanks for the assistance 🙂

🙌 2
borkdude13:02:19

babashka supports everything deps.edn :deps supports

borkdude13:02:34

in doubt, try to fetch the dep with deps.edn - it should work totally the same

pesterhazy11:02:02

Let's say I'm writing a tool called magic (which is actually true). I want to have a proper setup with bb.edn and namespace declarations, so here's the folder structure:

.
├── bb.edn
├── bin
│   └── magic
└── src/magic
    └── main.clj
Now I want to have a single script to call. This works:
#!/usr/bin/env bash
set -euo pipefail && cd "$(dirname "${BASH_SOURCE[0]}")/.."

exec bb -m magic.main "$@"
Now I can call magic from anywhere with a single command. However, in this way of doing things, the CWD (current working directory) is set to the root folder of the project (that's what cd does in the script). Oftentimes I want to keep the CWD, for instance if magic is to operate on files in the current folder. What's a good way to do this?

Sergio12:02:44

Maybe install the script in the system with https://github.com/babashka/bbin and allow the script to use current folder (by default) and have a -f option to pass an optional folder?

6
borkdude12:02:39

Yes, #C0400TZENE7

borkdude12:02:03

Or make a bash wrapper which sets:

bb --config "$(dirname "${BASH_SOURCE[0]}")/../bb.edn" -m magic.main "$@"
but bbin works cross platform

borkdude12:02:00

I am considering setting the --config flag automatically when you execute a script outside of the current directory, so it picks up on the bb.edn of the script, but I'm not sure if this will break any existing setups. Also this would only work for *nix, not on Windows, and bb aims to be a cross-platform tool. So in the end, bbin is the preferred solution.

eval202013:02:52

Alternatively use https://direnv.net/. Create $PROJECT_ROOT/.envrc with

PATH_add bin
export PROJECT_ROOT=$(expand_path .)
Then from anywhere in or under $PROJECT_ROOT you’ll have magic on PATH The script itself would then have bb --config "${PROJECT_ROOT}/bb.edn" -m magic.main "$@"

eval202013:02:30

(this is indeed limited to working from the project, else bbin FTW)

teodorlu14:02:36

For my latest scripts, I’ve copied the folder structure from https://github.com/borkdude/carve. 1. All dependencies are in deps.edn 2. bb.edn refers to deps.edn dependencies 3. bb.edn also gives a bbin directive for what I want the binary to be called. For local installation, I install with bbin install . or bbin install . --as myscript-dev if I want both a local binary and a proper install. Local installs automatically pick up any changes to your script, so it’s very easy make a change, run it again, etc; you don’t need to re-run bbin install. The “carve structure” also makes it possible to REPL into your project with both babashka and clojure.

👍 2
Shuai Lin15:02:40

what about adding /path/to/src/ to bb classpath? This way you dont need to change the cwd to call bb -m magic.main?

borkdude15:02:04

but all deps in path/to/project should also be added, which is what --config is for

👍 2
pesterhazy16:02:56

Thanks for all the suggestions. --config does exactly what I was looking for

borkdude15:02:40

cljfmt master now works with bb:

bb -Sdeps '{:deps {cljfmt/cljfmt {:git/url "" :git/sha "7dfd55d5dd0756f30311a90f206c2dd32e56d18b" :deps/root "cljfmt"}}}' -m cljfmt.main

awesome 4
💯 2
🎉 2
👏 2
2
lread15:02:34

Ya think james will go for a bb compatible badge?

borkdude15:02:34

Worth a shot ;)

👍 2
lread18:02:36

Nope! Oh well.

borkdude16:02:36

Added cljfmt to my bbin tools collection: https://github.com/borkdude/tools#cljfmt

🙇 2
escherize23:02:55

not sure what I am doing wrong:

$ bbin --version
bbin 0.1.8
$ bbin install 
{:coords
 #:bbin{:url
        ""}}
$ cljfmt --help
zsh: command not found: cljfmt

borkdude09:02:12

@U051GFP2V Do you have a fully functioning bbin installation?

borkdude09:02:44

i.e. did you add the .bbin dir to your PATH?

escherize17:02:15

Oh yeah, I’ll read the manual next time 🙈

escherize17:02:26

added the path and It works now

vlad_poh19:02:38

In babashka tasks is there an idiomatic way to prevent dependent tasks from rerunning when nothing has changed? filewatcher ?