Dependencies in components (version 0.2.12-alpha+)

[volisoft]

The new version of the tool introduced deps.edn for each component. While I understand the idea behind the changes in the recent version (like, using local roots in projects to conform with deps tool), I couldn't find clear guidance in the documentation about the proper usage of indicidual deps.edn in components and bases.

1. If 3rd party dependencies are specified in components, why is it required to duplicate them in root deps.edn in dev profile (as shown in example projects)?
2. Does it increase the chance of dependency version conflicts between components having different versions of same libraries?
3. If components explicitly specify dependency on 3rd party libraries, why the tool doesn't require explicit specification of 1st party dependencies (other components)?
4. Apparently, all components implicitly depend on Clojure language library. Why it's not specified in the individual deps.edn?

Note, the conclusions here are mainly drawn from the code examination in real-world-app repository. Still, this forum seems to be more appropriate for this discussion as it's exposed to a wider audience.

[furkan3ayraktar]

Let me try answering these questions.

1. IDEs like Cursive does not support the source/test code resolution through :local/root fully yet. That is why the duplication is necessary only in the root deps.edn. You can read in this issue.
2. Different components may have different versions but you have a chance to set which version you want to use in the project level. Having different versions might be useful in the several cases. One example case could be that you have a component which uses an old version of a library and you wrote another component with the same interface but later version of the library. This way you can have both components and migrate to never one in your projects gradually.
3. One of the important ideas behind the components and bases are that they are replaceable. The projects are the place where the components and bases are glued together. Enforcing dependencies between components removes this flexibility and makes it hard during the development.
4. You can do that if you want, but that would be a lot of duplication. It's easier to set Clojure dependency (and other generic dependencies) in the project level. This makes sense since you wouldn't be able to run different versions of Clojure once you put them together in a project.

The Polylith Gitbook explains these design choices in detail. I would highly recommend reading it if you haven't yet. If you have further questions or want to discuss about Polylith, you can reach out to the community at the #polylith channel of the Clojurians Slack.

[tengstrand]

Just wanted to complement with this.

1. The poly tool itself supports using the :local/root syntax in the root deps.edn file (the development configuration file), and some teams take advantage of this by using it to get rid of some code duplication (the tests still have to be specified as paths). If you use Emacs/Cider and/or VSCode/Calva then the :local/root syntax will work, but it's not supported by IDEA/Cursive.
2. The tool picks the latest library version, selected from the bricks included in each project + if the library is specified or overridden by the project.
3. Yes, components and bases only knows about interfaces. That's where we get the replaceability comes from.

[volisoft]

Furkan and Joakim, thank you for taking time to answer my question.
Thanks to your answers and with a bit of experimentation, it seems like following is the case. Dependencies, including 3rd party dependencies can be specified:

• only in component's deps or
• (old style) only in root/base/project deps.edn or
• have a combination of the previous two approaches

Please let me know if there are any cautions in either approach.

What I didn't realize is that it matters how dependency is specified.
Let's say, in dev profile in root deps.edn a component is listed in :extra-paths. In this case classpath won't include the component's dependencies. It also means that the component's dependencies should be duplicated in dev profile (or in other profile used to run clojure).
On the other hand, if component is resolved via:local-root then classpath will include the component's dependencies automatically and no duplication is needed.

Of course, this is behavior is imposed by deps tool, and it has nothing to do with polylith. Still it's useful to keep in mind the dependency management options as listed above. The rest of the questions can be inferred from those options.
Thank you for helping to articulate this.

[tengstrand]

It seems like you got it now!

And yes, because we build the poly tool on top of tools.deps, we are restricted to how that tool works, and the same is true about different IDEs.
I think it was a good idea to post your question here, because in Slack things often disappear after a while.

If you have any further questions, don't hesitate posting them here or in Slack.