Fork me on GitHub
#babashka
<
2021-12-16
>
cldwalker17:12:08

What do folks do for reusing deps.edn deps in bb.edn? For now I’m doing bb -cp $(clojure -Spath) but that invocation feels onerous to requires others to use for bb tasks. Perhaps something like {:deps {:deps.edn true}} in bb.edn would be a handy way to pull in these deps automatically

borkdude17:12:54

@cldwalker

{:deps {local/deps {:local/root "."}}}
:)

wilkerlucio18:12:10

wow, that's a great snippet to remember 🙂

cldwalker19:12:47

Thanks! Works great. At first I thought local/deps was something special but it can be anything. Mind if I document this in the book?

wilkerlucio20:12:36

hello, I have a folder with some babashka scripts, I like to run scripst from this folder, but having my working directory to be the current folder (to modify files with relative path to where I started the script), is there a way to do this?

borkdude20:12:21

add the scripts to your path?

borkdude20:12:52

that's what PATH is for?

wilkerlucio20:12:54

its not just the script, there is a bb.edn with configuration that I want to use with the script

wilkerlucio20:12:17

I use a script like

#!/bin/bash

cd /Users/wilkerlucio/Development/scraper-playground
bb [email protected]

wilkerlucio20:12:40

because I want make this flexible to add many things on this project and re-use around (they are for generic tools that I want to use in various places)

borkdude20:12:53

you could use babashka.deps/add-deps to add the deps in the script instead of using bb.edn and then just place it on the path

wilkerlucio20:12:37

yeah, but thats much more cumbersome, the path way I also plan to have larger script files that will be shared, bb.edn just makes all of this much more convenient

wilkerlucio20:12:54

but I see, I could use that with also extra classpath, I'll try something here 🙂

borkdude20:12:47

one thing that is definitely immutable in babashka is the current working directory, but deps and paths can be added dynamically

borkdude20:12:06

and you can use *file* to look up things relative to the script

borkdude20:12:51

e.g. (babashka.classpath/add-classpath (str (fs/file (fs/parent *file*) "src"))

borkdude20:12:42

If you find a way, please document it somewhere <3

👍 1
cldwalker20:12:36

I’d be curious to hear how it goes. I use a shell wrapper for running globally useful bb tasks - https://github.com/cldwalker/dotfiles/blob/4af3b54dca2ac4f4ef06f4208488817ca50ff445/.sh/functions#L45 . It may achieve what u want but I don’t think $BABASHKA_EDN is a public api

borkdude20:12:30

BABASHKA_EDN is used for tests. One problem with making that a public API is that relative dirs are for example resolved against the current working dir

wilkerlucio20:12:36

@cldwalker approach works great for me! the only adjust I had to make is change the :paths in my project to use absolute paths instead of relative ones

cldwalker20:12:42

@U04V15CAJ If I set BABASHKA_EDN=~/foo and ran from ~/bar, would tasks resolve relative to /foo or /bar?

cldwalker20:12:06

@U066U8JQJ Nice! My approach or the one borkdude was mentioning?

wilkerlucio20:12:34

yours, using BABASHKA_EDN

wilkerlucio20:12:53

I had to change the :paths part of my bb.edn to use absolute paths, otherwise it only works running from the repo directory

cldwalker20:12:02

Ah gotcha. One downside of absolute paths is that it’s not usable by others. Not saying that’s a problem for you but that’s been a problem for me if I want to share with others. I’ve resorted to using $BABASHKA_CLASSPATH to work around this but not happy with it as it doesn’t play nicely with any other bb script - https://github.com/cldwalker/bb-clis#global

borkdude20:12:48

This is exactly why isn't not a public API ;)

cldwalker21:12:09

good point. More thought required to strike a balance here

borkdude21:12:55

I once had the thought of when running a script and then bb.edn was relative to that script, to resolve deps relative to the script

borkdude21:12:02

This is kind of what Node.js does too

borkdude21:12:13

I just don't know what kind of trouble that will get me into

borkdude21:12:55

Maybe bb.edn deps should always be resolved relative to the bb.edn file, for starters. That doesn't seem like a breaking change

👍 1
borkdude21:12:51

but which bb.edn file should you use, the one relative to an invoked script, or the one in a current working dir... clojure does the latter

borkdude21:12:46

I certainly like the idea of the first

cldwalker21:12:10

I’m not sure about multiple bb.edn’s but if I’m explicitly passing one I’d prefer it to be relative to the specified one

wilkerlucio21:12:46

yeah, agree on the explicit one like @cldwalker

cldwalker21:12:01

Handling multiple bb.edn’s gets into merge behavior for tasks as well as deps. Perhaps leave that for later to see how people use global tasks with the explicit bb.edn

borkdude21:12:01

cool, relative to the specified one, let's go with this idea for a moment. would this solve both @U066U8JQJ and @cldwalker's script problem?

borkdude21:12:11

ok, so exactly as specified here with --bb-edn right? https://github.com/babashka/babashka/discussions/869

cldwalker21:12:05

Looks like it. Happy to try a build before release

borkdude21:12:25

@U066U8JQJ @cldwalker the proposal also adds --context to which the relative paths are resolved, but it seems to be it would be logical that this is the same as the bb.edn, it doesn't seem necessary to also add that

👍 1
cldwalker21:12:31

Agreed. I think it adds needless complexity/configurability. It could always be added later as better understood use cases emerge

borkdude22:12:37

It seems @UFDRD93RR has posted a reaction in that thread in which he find the --bb-edn option magical and proposes something different. It's unclear to me what the trade-offs are

borkdude22:12:35

perhaps @U7ERLH6JX can also re-iterate his thoughts here

borkdude22:12:59

ah I missed a couple of reactions there due to being collapsed

borkdude22:12:38

so yes, we could do --bb-edn or --config (maybe a better name since you can point to any edn file)

borkdude22:12:51

and add more options later, but this doesn't seem necessary now

borkdude22:12:01

One more alternative thought: would an alternative be something like clj -Tsome-tool for babashka?

cldwalker22:12:24

That’d be cool but I think that’s taking on a lot more functionality than I’m asking for. Just looking for a path forward on global tasks that others can use for now :)

borkdude22:12:02

@cldwalker with global tasks, do you mean :tasks tasks?

borkdude22:12:58

do you mean that the script on PATH would look at its relative bb.edn dir and then do (babashka.tasks/run ...) on some command line argument?

cldwalker22:12:28

Sorry. Going to be afk but I’ll elaborate later in the specified issue

👍 1
lispyclouds08:12:35

just as a gist if it helps, my thoughts when proposing this was to to use a common bb.edn and use it as a project file for multiple sub dirs for example a monorepo setting of mostly common tech based projects. Hence i thought of both --config and --context as when the CI or some orchestration calls bb, it sets both of these based on which dir it needs to do things in. Got the idea from the way we handle docker files where the context matters when the COPY commands runs for instance.