Fork me on GitHub

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



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


wow, that's a great snippet to remember 🙂


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?


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?


add the scripts to your path?


that's what PATH is for?


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


I use a script like


cd /Users/wilkerlucio/Development/scraper-playground
bb $@


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)


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


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


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


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


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


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


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

👍 1

I’d be curious to hear how it goes. I use a shell wrapper for running globally useful bb tasks - . It may achieve what u want but I don’t think $BABASHKA_EDN is a public api


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


@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


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


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


yours, using BABASHKA_EDN


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


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 -


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


good point. More thought required to strike a balance here


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


This is kind of what Node.js does too


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


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

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


I certainly like the idea of the first


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


yeah, agree on the explicit one like @cldwalker


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


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?


ok, so exactly as specified here with --bb-edn right?


Looks like it. Happy to try a build before release


@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

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


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


perhaps @U7ERLH6JX can also re-iterate his thoughts here


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


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


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


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


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 :)


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


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?


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

👍 1

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.