Fork me on GitHub
#polylith
<
2021-05-19
>
tengstrand15:05:47

I just added support for :override-deps in projects to the issue-66 branch.

tengstrand15:05:03

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).

seancorfield15:05:22

I’m curious how that works in Polylith, since it can only be used under an alias?

seancorfield15:05:09

: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)…?

tengstrand16:05:39

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).

seancorfield16:05:17

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).

seancorfield16:05:51

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.

tengstrand19:05:39

Okay, let’s see how it turns out.