This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-08-04
Channels
- # announcements (7)
- # babashka (32)
- # beginners (106)
- # bristol-clojurians (10)
- # cider (6)
- # clj-kondo (5)
- # cljdoc (10)
- # clojure (110)
- # clojure-australia (10)
- # clojure-dev (6)
- # clojure-europe (12)
- # clojure-nl (2)
- # clojure-norway (16)
- # clojure-spec (9)
- # clojure-uk (59)
- # clojurescript (105)
- # community-development (2)
- # conjure (46)
- # cursive (12)
- # data-science (1)
- # datalog (26)
- # datomic (37)
- # docker (4)
- # emacs (10)
- # events (1)
- # fulcro (8)
- # graalvm (2)
- # jobs (1)
- # jobs-discuss (1)
- # malli (24)
- # meander (13)
- # off-topic (52)
- # pathom (4)
- # polylith (17)
- # proletarian (4)
- # react (1)
- # rewrite-clj (4)
- # shadow-cljs (56)
- # sql (21)
- # xtdb (14)
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.
roger that
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 https://github.com/cursive-ide/cursive/issues/2554, 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.
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!
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. 🙃
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!