This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-05-12
Channels
- # announcements (4)
- # asami (3)
- # babashka (18)
- # babashka-sci-dev (2)
- # beginners (55)
- # calva (18)
- # clj-commons (23)
- # clj-kondo (2)
- # cljfx (7)
- # cljs-dev (15)
- # clojure (96)
- # clojure-europe (43)
- # clojure-losangeles (3)
- # clojure-nl (2)
- # clojure-uk (11)
- # clojurescript (1)
- # datalevin (2)
- # datomic (10)
- # events (1)
- # google-cloud (4)
- # gratitude (16)
- # helix (3)
- # hyperfiddle (63)
- # inf-clojure (13)
- # introduce-yourself (4)
- # ipfs (2)
- # jobs (2)
- # jobs-discuss (12)
- # leiningen (7)
- # lsp (15)
- # off-topic (38)
- # polylith (24)
- # portal (27)
- # remote-jobs (8)
- # sci (27)
- # spacemacs (5)
- # specter (1)
- # sql (5)
- # xtdb (41)
@borkdude I ran into a use case for an explicit download-pods
subcommand we had briefly discussed (vs. just invoking anything to download them): When I have a mix of local and non-local pods in Docker images, I currently have to get the Linux binary into the same path inside the container (which is sometimes a pain) or bb will bail b/c that's not there. If we had a download-pods
subcommand, it could ignore local pods when invoked and not care if they weren't there. Pretty niche use case, I know. But wanted to mention I'd found one. 🙂
An alternative workaround would be if there were a way to specify merged config overrides at the CLI. Something like: bb --config-edn '{:pods {my.local-pod {:path "/container/path"}}}'
and it would then deep-merge that into the bb.edn config so it would just override the :path
for that one pod. That's not already a thing, is it?