Fork me on GitHub

From the migration doc: • Notice that the `development` environment, with its `./deps.edn` file, is not converted to use `:local/root` and the reason is that the `:local/root` definitions will not be picked up by all IDE's as source code. Does that mean that deps.edn will still contain all of the deps that each brick depends on?


That is correct! The root deps.edn should look same as before migration, except that the :polylith key and its value should be removed.


A deps.edn file in the root of the workspace can safely use :paths/`:extra-paths` so no change there.


assuming all editors supported :local/root then the deps in the root deps.edn could fall away?


I imagine that would be preferable?


Yes, the poly tool treats the development project in the same way as other projects when it comes to dependency management. The :local/root syntax already works in Emacs/Cider and VSCode/Calva, so if @U0567Q30W adds support for :local/root for Cursive as I suggest in, then I think most teams could quite safely start using the :local/root syntax in all their projects, development included. The problem now is if all the teams in an organisation only use supported IDE’s and decide to use the :local/root syntax today, then if a new developer arrives that uses Cursive, you have to go back and use paths in dev, so it’s maybe better to wait for support in Cursive, because it’s a quite widely used IDE.


And yes, it would be better to only use the :local/root syntax everywhere (but still support paths). It would be consistent across projects and simpler.


thanks for the detailed explanation 🙂

👍 2

One consideration there aside from Cursive - if you change dependencies in a local/root project, the CLI won't see them unless you use -Sforce so staying with paths/extra-deps in the dev alias might be more convenient while actually developing (for starting your REPL).


But it's good to know, since we could change our setup at work and that would eliminate a lot of lib duplication in the dev alias (we have no Cursive users). That would be more inline with how we used to do it before Polylith.


Of course the create command tells you to add paths not local/root deps to the dev alias:grinning:


We just switched the development project at work over to use :local/root like all the other projects and it cleaned up the alias a lot since it no longer needs to duplicate the lib dependencies from all our bricks! Nice!

👏 3
Matt Ielusic15:08:07

I'm migrating a project that uses Integrant to polylith. Should a component's Integrant setup - init-key/`halt-key!`/etc - be in its interface? I had thought the keys a component uses, and the specs for those keys, are part of a component's "interface" (in the general sense). But I double-checked Sean Corfield's example web app, and there the setup for the Component library is done outside of any interface namespace. And Component and Integrant are very similar. But they are not identical - and one difference is that Integrant configuration is typically done in .edn files that potentially differ between artifacts. And even if a component's init-key function is never used by another component, surely the keys that need to be configured should be publicly exposed?


It’s good to say in the beginning that I did not work with Integrant before. In my opinion, a components state and its management is an implementation detail. Even in the case that you need to call functions to start/stop the state, I would expose start and stop functions in the components interface, but not Integrant specific things. This way, you can change the way (library) that you manage the components state in the future without changing the interface. PS: This is not an official Polylith recommendation for Integrant but my own opinion based on how I use Polylith with state management libraries. 🙃

Matt Ielusic19:08:47

Integrant tends to rely on namespaced keywords (EG (defmethod integrant/init-key ::something [...]) ) - does it matter if there are then maps flying around with keys like :top-level-ns.component-name.implementation.another-ns/something ? Would keys like :top-level-ns.component-name.interface/something be preferable?


I guess I would instead of ::something in the implementation use it like component-name/something so that its neither dependent on interface ns nor implementation. Also, component names are unique, so, that will give you uniqueness, if needed.


We just switched the development project at work over to use :local/root like all the other projects and it cleaned up the alias a lot since it no longer needs to duplicate the lib dependencies from all our bricks! Nice!

👏 3