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.