This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-04-09
Channels
- # announcements (26)
- # asami (1)
- # babashka (7)
- # beginners (51)
- # calva (1)
- # cider (18)
- # clj-kondo (6)
- # clj-together (1)
- # cljsrn (4)
- # clojure (78)
- # clojure-australia (3)
- # clojure-europe (25)
- # clojure-losangeles (1)
- # clojure-nl (2)
- # clojure-serbia (4)
- # clojure-spec (23)
- # clojure-uk (19)
- # clojurescript (23)
- # community-development (13)
- # deps-new (1)
- # emacs (24)
- # figwheel-main (5)
- # fulcro (61)
- # graalvm (1)
- # honeysql (11)
- # jobs (1)
- # lsp (7)
- # malli (4)
- # meander (6)
- # membrane (3)
- # off-topic (10)
- # polylith (13)
- # quil (7)
- # re-frame (54)
- # reagent (18)
- # remote-jobs (2)
- # shadow-cljs (81)
- # sql (16)
- # tools-deps (12)
- # xtdb (10)
I’m wondering: how many folks are using :override-deps
(or :default-deps
— but more specifically :override-deps
)?
We have small-ish monorepo with some libraries, and fulcro front and back ends. 0 uses of override-deps
Thanks. Yes, I should have mentioned that “Folks using a monorepo setup and not using :override-deps
is also a very useful data point for me”.
I only use it in my personal deps.edn, and mostly for quickly testing version compatibility. I have yet to see it in a project edps.edn file
Using both in a monorepo setup, or at least trying to. We keep encountering odd rough edges where the version replacement doesn’t seem to happen correctly
we use :default-deps to synchronize direct dependencies among monorepo modules. none of them are supposed to use version coordinates, but inherit from default-deps, which is in an alias that must always be active
we use :override-deps to address version-pinning problems for transient deps, e.g. to address CVEs on things we don’t depend on directly
@U09R86PA4 I’m curious how you specify the lib deps where :default-deps
plays a role? some/lib nil
?
We use some/lib {}
with :override-deps
. I seem to recall some tooling having a hard time with nil
but maybe that’s just in the past. I’m just wondering how much value it is really adding to our setup, since it forces every invocation to specify an alias to pick those overrides up.
If we were using it solely to address transitive deps/CVEs, I wouldn’t be so averse to just duplicating the lib specs — I think Jackson is about the only thing where we have to force an older version due to incompatibilities with some other lib we use…
(background: we use it heavily at work but I’ve been looking at Polylith a lot recently and there doesn’t appear to be anywhere to “hang” a single alias with all of the “pinned” deps for a project — and I know our heavy use of :override-deps
is somewhat core to our struggles to “fit” the CLI/`deps.edn` world — so I’m thinking that :override-deps
is very rarely used in the wild)
Thanks. Yes, I should have mentioned that “Folks using a monorepo setup and not using :override-deps
is also a very useful data point for me”.