Fork me on GitHub
#polylith
<
2024-06-08
>
stephenmhopper11:06:37

When setting up a deps.edn file for a component / base / project I'm currently specifying the dependency names as well as the versions. I have a deps.edn in the root of my repo which already has all of these dependency names + versions. Is there a way to tell poly / deps to just pull from there?

seancorfield18:06:36

Why are the bricks' deps duplicated into your workspace-level deps.edn file?

seancorfield18:06:36

If your top-level deps.edn file uses :extra-deps to refer to the bricks, the dependency/version from those bricks will be used -- with no need to duplicate them.

stephenmhopper20:06:16

Whatever example I followed used :extra-paths to point to the source and resource roots in each brick and the :extra-deps entry in my root deps.edn file just points to 3rd party libraries. I could probably update that to point to the individual bricks. Although that only partially solves the problem. I could still easily have a situation where two bricks both depend on the same 3rd party library, but neither one depends on the other. How do you typically handle that situation? Just hard code the same version number in both locations? I'd really like to just specify the dependency version number in one centralized location

tengstrand21:06:19

You can use poly libs :update to update all libraries to the latest version. Otherwise, you need to update all library versions manually. poly libs will list the libraries in order, and if you only have one line per library, then you use the same version of each library everywhere.

seancorfield23:06:06

The :extra-paths stuff is old and was only done to support Cursive. But Cursive fixed their bug and now you can use :extra-deps instead and only specify the libs in bricks. As for duplication, yes, we put lib deps with versions in every brick that needs them. The alternative is to put them in every project (including :dev), so they're still going to be duplicated. We have two dozen projects and over 200 bricks so we've gone with lib deps in bricks. And as Joakim says, you can rely on poly tooling for updates if you want. We tend to use find'n' replace via our editor and we generally keep all our libs at the latest version and don't feel it's a burden. We do it manually so we have more control: we have some libs that we can't update (yet).

stephenmhopper11:06:06

I updated my root deps.edn to just point to the necessary bricks instead of also specifying all of the dependencies. It's much cleaner now, thank you. I'll continue to just specify third party library version numbers in each brick's deps.edn as necessary since it sounds like there's not a better way at this point. Thanks again!

👍 1
1
Samuel Ludwig14:06:28

ohhh the extra-paths->`extra-deps` is news to me, nice that'll clean up my deps a bit :^)

👍 1