This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-05-19
Channels
- # aleph (11)
- # announcements (1)
- # babashka (9)
- # beginners (90)
- # calva (6)
- # clj-kondo (24)
- # cljs-dev (26)
- # clojure (92)
- # clojure-europe (48)
- # clojure-nl (1)
- # clojure-spec (4)
- # clojure-sweden (2)
- # clojure-uk (41)
- # clojurescript (60)
- # code-reviews (1)
- # conjure (6)
- # core-logic (3)
- # datascript (1)
- # datomic (3)
- # deps-new (1)
- # depstar (4)
- # dirac (3)
- # emacs (8)
- # fulcro (1)
- # helix (27)
- # introduce-yourself (2)
- # jobs (1)
- # off-topic (4)
- # pathom (2)
- # polylith (8)
- # re-frame (3)
- # remote-jobs (1)
- # shadow-cljs (5)
- # spacemacs (2)
- # tools-deps (22)
- # vim (3)
- # xtdb (27)
I just added support for :override-deps
in projects to the issue-66
branch.
Changes (commit 9c018fac09fe80d405229f76b703f142700a70a6:
- updated version to issue66.06
- added support for :override-deps in projects.
- fleshed out the documentation under the libraries section.
- :git/url dependency now working for the test command (bug fix).
I’m curious how that works in Polylith, since it can only be used under an alias?
:dev
is the only alias that Polylith “supports”, but I suppose you can add :override-deps
under :test
and :uberjar
too, if a brick/project needs to force a specific version (for transitive deps)…?
Yes, I just added it for :dev
right now, but will add it for :test
later. Other aliases like :uberjar
is not used by the`poly` tool itself. It adds value to be able to override a dependency for a project, but not for a brick, which is therefore not supported (bricks are “brought to life” when put together into a project).
And I guess if a brick needs a specific version, it’ll have its own (3rd party lib) :deps
anyway although by default the most recent version should “win” in a full set of deps.edn
merges based on the behavior of tools.deps.alpha. We ended up making Jackson a top-level dep in the project that needs it pinned, and we also added it explicitly to our equivalent of :dev
(`:everything` for our “legacy” monorepo REPL).
We could have used :override-deps
in :everything
and the :test
/`:uberjar` aliases for that specific project and it would have had the same effect. I’ll need to give that some more thought. Currently, this particular project is just a “regular” subproject in our repo, not yet a Polylith project
.
Okay, let’s see how it turns out.