I’m wondering: how many folks are using :override-deps
(or :default-deps
— but more specifically :override-deps
)?
(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)
We have small-ish monorepo with some libraries, and fulcro front and back ends. 0 uses of override-deps
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
@favila I’m curious how you specify the lib deps where :default-deps
plays a role? some/lib nil
?
yes
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…