My assumption is that the pod is built for amd64 and not arm64, but I don't really know how to resolve this.

In the meantime, I'll try to verify the assumption by seeing if everything works on amd64.

@U054AT6KT Could you paste the long stack trace in a gist instead of in the channel?

There is one release for linux aarch64: https://github.com/babashka/pod-babashka-aws/releases

But if you upload the one you downloaded on your own computer, it might not match that architecture

There is an issue here with some ideas for improvement: https://github.com/babashka/babashka/issues/1316

Makes sense. I did confirm that it worked on amd64, so it is an arch issue. I think I'll switch to awyeah-api so I can make blambda work with deps. 😉

aw yeah :)

You could also just manually download the aarch64 pod

but yeah, I think awyeah might be good to explore

Yeah, I could. Or I could also use an amd64 lambda. The choices are paralysing! 😱

At least you're not considering #nbb - one less choice!

it does use the standard tools deps stuff for bb.edn - the only thing that has been ported is the bash script which was converted to clojure and is part of bb

I vaguely remember that there's some environment variable that one can set to tell clojure to look for the local cache, but I can't craft the right search to find it.

:mvn/local-repo

In the deps.edn, not an env var

Can you set that from the command line, or does it have to be added to deps.edn?

In bb's case, you can add it to bb.edn if you want to do stuff with deps for bb

clojure has -Sdeps to merge options, but bb doesn't have this yet. What you can however do is create another bb2.edn and then refer to that with --config

For posterity, I found :mvn/local-repo documented here: https://clojure.org/reference/deps_and_cli

yes, the "reference" usually has all the stuff documented, where "guide" is usually a gentle introduction which covers a lot but doesn't cover all of the options

It took me a few levels of searches before I realised that "maven cache" is the magic term. 😉

I think the easiest way out for me is probably to use :mvn/local-repo in deps.edn. Thanks both of you for the help! 🙂

Hrm, setting :mvn/local-repo "/tmp/deps-mvn-repo" in my deps.edn and running bb help still seems to use ~/.m2/repository.

bb does look at your deps.edn - unless you invoke bb clojure

or unless you write something like {:deps {current/deps.edn {:local/root "."}}} in bb.edn

Here's my bb.edn:

{:paths ["."]
 :deps {local/deps {:local/root "."}}}

{:deps {com.cognitect.aws/endpoints {:mvn/version "1.1.12.206"}
        com.cognitect.aws/s3 {:mvn/version "822.2.1109.0"}
        com.grzm/awyeah-api {:git/url ""
                             :git/sha "0fa7dd51f801dba615e317651efda8c597465af6"}}
 :mvn/local-repo "/tmp/deps-mvn-repo"}

yeah, hmm, this ain't gonna work I realize, I think because the :mvn/local-repo isn't inherited from external deps

This is what the Babashka Book says to do if you want to use deps.edn, right?

yes, if you want to include the deps from deps.edn

Ah, OK. Is there a way around this in Babashka?

yes, add it to bb.edn

OK, so keep all of the deps in bb.edn instead?

you could keep the deps local/root thing to refer to deps.edn, but the mvn/local-repo isn't inherited from other files

And add :mvn/local-repo at the top level of bb.edn?

yes

We should really have something like -Sdeps for this

That worked as advertised! 🎉

Added a comment here: https://github.com/babashka/babashka/issues/808

Whoa, more weirdness! With a bb.edn like this:

{:paths ["."]
 :deps {com.cognitect.aws/endpoints {:mvn/version "1.1.12.206"}
        com.cognitect.aws/s3 {:mvn/version "822.2.1109.0"}
        com.grzm/awyeah-api {:git/url ""
                             :git/sha "0fa7dd51f801dba615e317651efda8c597465af6"}}
 :mvn/local-repo "/tmp/deps-mvn-repo"}

Downloading: com/cognitect/aws/s3/822.2.1109.0/s3-822.2.1109.0.pom from central
Downloading: org/clojure/clojure/1.11.1/clojure-1.11.1.pom from central
Downloading: com/cognitect/aws/endpoints/1.1.12.206/endpoints-1.1.12.206.pom from central
Downloading: org/clojure/core.specs.alpha/0.2.62/core.specs.alpha-0.2.62.pom from central
Downloading: org/clojure/pom.contrib/1.1.0/pom.contrib-1.1.0.pom from central
Downloading: org/clojure/spec.alpha/0.3.218/spec.alpha-0.3.218.pom from central
Downloading: com/cognitect/aws/s3/822.2.1109.0/s3-822.2.1109.0.jar from central
Downloading: org/clojure/clojure/1.11.1/clojure-1.11.1.jar from central
Downloading: com/cognitect/aws/endpoints/1.1.12.206/endpoints-1.1.12.206.jar from central
Downloading: org/clojure/spec.alpha/0.3.218/spec.alpha-0.3.218.jar from central
Downloading: org/clojure/core.specs.alpha/0.2.62/core.specs.alpha-0.2.62.jar from central

because of caching I think. Use --force

(which I'll rename to just -Sforce because that's what it does)

Messing with your mvn repo (deleting stuff) isn't what the deps tooling expects

Haha, the deps tooling doesn't know me very well. 😉

That worked. Oddly enough bb help --force didn't download the deps, but bb tasks --force did. :man-shrugging::skin-tone-2:

That may be because bb help just prints the help and doesn't process any other flags

The official syntax is bb --force .... - force is a global option

The help output will also tell you that ;)

[jmglov@laurana:~/Documents/code/clojure/s3-log-parser/src]$ bb --force tasks

Downloading: com/cognitect/aws/s3/822.2.1109.0/s3-822.2.1109.0.pom from central
Downloading: com/cognitect/aws/endpoints/1.1.12.206/endpoints-1.1.12.206.pom from central
Downloading: org/clojure/clojure/1.11.1/clojure-1.11.1.pom from central
Downloading: org/clojure/core.specs.alpha/0.2.62/core.specs.alpha-0.2.62.pom from central
Downloading: org/clojure/pom.contrib/1.1.0/pom.contrib-1.1.0.pom from central
Downloading: org/clojure/spec.alpha/0.3.218/spec.alpha-0.3.218.pom from central
Downloading: org/clojure/clojure/1.11.1/clojure-1.11.1.jar from central
Downloading: com/cognitect/aws/endpoints/1.1.12.206/endpoints-1.1.12.206.jar from central
Downloading: com/cognitect/aws/s3/822.2.1109.0/s3-822.2.1109.0.jar from central
Downloading: org/clojure/spec.alpha/0.3.218/spec.alpha-0.3.218.jar from central
Downloading: org/clojure/core.specs.alpha/0.2.62/core.specs.alpha-0.2.62.jar from central
----- Error --------------------------------------------------------------------
Type:     java.lang.Exception
Message:  File does not exist: tasks

I see... this is worthy of a bug report :)

(we should migrate this stuff to #babashka-cli :)

That's actually what I typed, I just got it backwards in Slack. 😬

OK, I'll continue the thread there, because now I need some advice.

I can file a bug report as well.

I meant, we should migrate the CLI handling of bb to the bb.cli library - it's all manual right now

but yes, bug report is fine

Ah, now I get you.

OK, so I thought a little more about what I want to do. Here's the situation: • I have a bb app (project? dunno what to call it) that will run as a AWS Lambda. It has its deps specified in lambda/bb.edn • I have another bb.edn which is used for provisioning the lambda and associated layers; let's call it infra/bb.edn • infra/bb.edn should have a deploy-deps-layer task that reads lambda/bb.edn, uses the Clojure CLI to download JARs from Maven and/or Git into a scratch directory (`/tmp/lambda-deps`, for example), then zips that directory up and creates a layer for it.

So I need to set both :mvn/local-repo and the GITLIBS environment variable. My current thinking is that I have a task in infra/bb.edn that reads lambda/bb.edn, writes a /tmp/lambda-deps.edn, then invokes clojure to do the deps downloads.

Does this make sense? If so, what clojure command would I run from Babashka to make this work?

Btw, I think #holy-lambda has figured all of this stuff out already for bb on AWS ;)

Fyi, you can also set gitlibs via Java system property clojure.gitlibs.dir

Although I guess you can't set that in the jvm that would matter so nvm

Holy Lambda is awesome, but: a) it uses Docker, which I don't wanna, and b) it lets me get away with not understanding how all this stuff works. 😉

How does bb itself invoke tools.deps? Does it literally execute clojure?

no, it executes deps.clj's main function: https://github.com/borkdude/deps.clj

If I want to use deps from a bb task, would you recommend doing the same? Does bb provide any helper functions for this?

deps from a bb task: explain

bb tasks support :extra-deps if you need extra deps in a task

Haha, I'm about to link a gist that will make you lose your lunch. Do not look directly at this gist!

https://gist.github.com/jmglov/74aa9cd7c508c22375dd018b6b72689e

Doesn't quite work, but at least you see what evil magicks I'm playing with here.

It basically almost works.

@U054AT6KT You can use (with-out-str (babashka.deps/clojure ["-Spath" "-Sdeps" ...])) as well, if you like. babashka.deps/clojure is basically the same as invoking deps.clj's main function

Ah, that seems much nicer!

(clojure [...] {:dir ...})

is the syntax

So the next arg after -Sdeps is the literal EDN string, right? So then I don't have to spit deps.edn to the work-dir.

yes, just an EDN map will do as well

That's much much nicer than having to set :dir and all. Thanks!

@U054AT6KT FWIW i've had luck using clojure.tools.build/uber, passing it :exclude ["^clojure[/].+"] to make zips(uberjars) to deploy babashka projects to lambda (I also had an aversion to using docker for this)

@U064UGEUQ babashka supports bb uberjar for this as well

yup I have a version using that too 🙂 Currently using the build tool one because it's more similar to the non-bb deploy code and avoids shelling out

I also have the requirement to be able to edit the code in the AWS Console, so I want to deploy the deps as a layer but not include the lambda sources. Maybe this can be accomplished with an uberjar, but it would require removing paths from the bb.edn or deps.edn as far as I can tell.

I repeat: bb uberjar produces an uberjar from bb.edn :)

no JVM required

For my use case, I’d need to preprocess bb.edn to remove the lambda sources, though. Or maybe you weren't replying to me?

I was blabbering in general, just broadcasting generally useless info haha

Btw, ffz comes to mind as well. Some people use it in combination with #babashka-neil

sorry, fzf was the name: https://github.com/babashka/neil/issues/16

you can launch fzf from babashka with babashka process, this works great