This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-12-16
Channels
- # adventofcode (43)
- # announcements (31)
- # aws (2)
- # babashka (58)
- # babashka-sci-dev (4)
- # beginners (107)
- # calva (11)
- # cider (25)
- # clj-commons (8)
- # clj-kondo (24)
- # clojure (35)
- # clojure-argentina (1)
- # clojure-europe (25)
- # clojure-italy (5)
- # clojure-nl (11)
- # clojure-norway (39)
- # clojure-spec (11)
- # clojure-uk (3)
- # conjure (2)
- # core-async (19)
- # cursive (33)
- # data-science (2)
- # datomic (50)
- # deps-new (1)
- # emacs (3)
- # events (4)
- # figwheel-main (10)
- # fulcro (63)
- # graalvm (7)
- # holy-lambda (17)
- # introduce-yourself (1)
- # java (15)
- # jobs (1)
- # jobs-discuss (7)
- # malli (24)
- # meander (16)
- # nextjournal (19)
- # off-topic (2)
- # polylith (4)
- # portal (10)
- # re-frame (3)
- # reagent (19)
- # reitit (14)
- # releases (2)
- # remote-jobs (1)
- # reveal (19)
- # shadow-cljs (1)
- # sql (21)
- # testing (4)
- # xtdb (22)
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
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?
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
#!/bin/bash
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
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
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 - https://github.com/cldwalker/bb-clis#global
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
Maybe bb.edn deps should always be resolved relative to the bb.edn file, for starters. That doesn't seem like a breaking change
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’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?
yup 🙂
ok, so exactly as specified here with --bb-edn
right?
https://github.com/babashka/babashka/discussions/869
sounds good
@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
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
so yes, we could do --bb-edn
or --config
(maybe a better name since you can point to any edn file)
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?
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.