Clojurians Log v2

Good discussion! I had indeed followed @mark354’s approach of just putting my defmethods in each component. I don't mind being tightly coupled to integrant though in this application.. But I do find it a bit messy that the init-key's are all over the place. Might look into this approach of putting them in bases. However this runs the risk of duplicate keys (if 2 bases use the same components for example)? thinking-face

@mstoyukhin Has made an https://cljdoc.org/d/polylith/clj-poly/0.2.20-SNAPSHOT/doc/example-systems#integrant-system for Integrant, that you can have a look at.

However this runs the risk of duplicate keys (if 2 bases use the same components for example)?@patrix Normally, you will not get into such naming collision if you follow the Integrant’s approach for naming components (system “keys”) with namespace-qualified keywords and distributing your Integrant components between separate namespaces accordingly. Example: • workspace sets the :top-namespace to be "glob.uniq" • we have bases alpha and omega • each of them uses a component called fred • for the sake of simplicity, each declares a dedicated top-level ns for fred • we end up with namespaces glob.uniq.alpha.fred and glob.uniq.omega.fred • following the Integrant’s convention for keys (see load-namespaces fn docstring), we name them :glob.uniq.alpha/fred and :glob.uniq.omega/fred, respectively Voila! Now you can mix and match these two freds within Integrant systems of your workspace however you like. It should also be noted that if it is necessary to use 2+ instances of a component within the same base/system, the problem is solved by using unique name aliases. Following the example above, fred can be aliased e.g. as busy-fred and lazy-fred, which are defined in namespaces with corresponding names. But that’s just one approach among many.

You’re right. I meant duplicate defmethods

you can also use composite keys

I guess I would need to not require multiple bases from my development project user.clj to avoid this.

there's one more thing you can use

given component fred you can define functions there and leave it integrant-free, and create an integrant-fred component (or fred-integrant) which just does the defmethods over fred's interface

can then use integrant-fred with multiple bases if needed

(and still swap the fred implementation underneath)

sure it's double the components but isn't this what poly is for?

Right. Might be better. Let’s say I have two projects/bases that both use the same component. I’d have to define the init-key method in both but it would need to be the same method defined twice. A -integrant component that pairs with the actual would prevent that and prevent any issue of loading both bases at the same time in my development project.

And would provide a clear indication to humans working on the code where to find the init-key methods

@imre Yes, this is a legit approach too. Still, I’d prefer to leave a single system-agnostic component implementation for fred and keep all parts of the actual system inside a particular base. That way we won’t run into the issue mentioned by @seancorfield, when we end up with multi-methods spread across entire codebase. (This all depends on the size of the codebase/workspace though, but can be tough on larger ones.)

well, the approach I suggested would keep all ig multimethods in components having integrant in their names

so it's still quite restricted yet reusable

and allows room to use different lifecycle management libs between projects if you so wish - mount-fred clip-fred etc

@mstoyukhin what I’m thinking with your approach is in the development project, if you require two bases that both use the Fred component and both define an init-key method with the same name …. That seems like it would cause a problem. Both in having duplicate methods of the same name and in having to keep in sync both implementations of the methods. Solved IMP by @imre ‘s approach but I’ll have to experiment and find out!

> both define an init-key method with the same name Which I never suggested. All system keys must be unique, ideally globally unique.

having to keep in sync both implementations of the methodsWhile this can be true, there are situations when you need to have them different (not in-sync), e.g. when different bases provide different dependencies/input parameters for fred’s instantiation. It all matters and depends on the context (of a particular project). DRY is not an absolute.

That’s also an interesting point

So far I’m just imagining/extrapolating from my own code base

While walking lol

Yeah, that’s ok. In fact, I had this very situation — with two Integrant bases using (almost) the same set of shared components within the workspace — on a real commercial project. The above approach could solve the issue of running both in a single Integrant system, which is a usual case with development project. (Though we ended up never actually doing so, because, what for? These bases were mutually exclusive, since the second one was a replacement artifact for the first one.)

in either case, what stands out is: separate the component (stateless/implementation) from its stateful elements (integrant init-keys/component lifecycles), whether that's in other components or directly within the bases, depending on how the projects are structured. in my case, a lot of statefulness is the same between projects or bases (e.g. web server, db connection, db migrations, etc), so the -integrant components approach would make sense to me.

Interesting discussion. I hadn't thought about the ig keys needing to be globally unique -- that's not a problem with Component as you can build arbitrary systems from shared components and have multiple instances of Components in a single system easily, because the "program" names everything when it assembles the system.

They only need to be unique within the system you're launching

(ig keys)

In a config map you can use composite keys to launch multiple instances of something

Wrt multimethods the keys there should still be unique within a classpath I suppose. But that's just like that with namespaces. Our ig keys match pretty well with their containing nses so we aren't seeing collisi9ns

Thanks all. In fact, my problem with integrant was less about polylith, and more that I was essentially passing my whole 'system' to many 'components'. The fix, of course, was to include only local dependencies in a local environment. So once I sorted that, having a polylith component define integrant multimethods seems fine, and trying to only use integrant in a base, and not as the definition of the component 'state' wouldn't work. I've now merged my polylith experimental branch into my 'main' as I much prefer the polylith approach to modularising my code. I'm porting a Java (Apple WebObjects) application currently, and think the polylith approach will make ongoing work much easier. So thank you!

My current code: https://github.com/wardle/pc4

Some of my polylith components are simply wrappers around external libraries, because that's what I had before... so perhaps not a very good example sorry!

My integrant configuration is derived from https://github.com/wardle/pc4/blob/main/components/config/resources/config/config.edn and I think this will need to be workspace-wide.... but obviously different bases might conceivably choose different keys to load.

nice! I've also gone with an approach as discussed before, where now the multimethods are defined in separate components.. It's a bit cleaner though with an extra level of indirection. However that extra level helps avoiding searching all over the codebase for where those methods are defined, just look for *-integrant components.

Current status :)

Happy to hear that you have had a good experience with Polylith so far! My advice is that you search for "in:#polylith integrant" because this has been answered earlier by users that use Integrant. Hope that helps.

Thank you! Missed those posts. I'll have a look.

I'll also note that Component does not require a bunch of defrecords -- you can attach start/stop implementations to things as metadata. You only need an associative thing (hash map or record) if you want dependency analysis. If you need dependencies but no start/stop, use a plain hash map. If you need start/stop but no dependencies, use anything that carries metadata (`next.jdbc` uses a (fn ...), for example). If you want your Components to implement other protocols etc., use a record -- we often implement IFn on our Components at work to return some specific part of the state.

That’s interesting. Thanks! I am quite attracted to the Component approach in which I can have a plain function in my polylith interface - the multimethod approach in integrant has been excellent but perhaps one abstraction more than is needed with polylith - and with polylith I can see I might want a master config file but wiring up the runtime ‘system’ is more a ‘function’ of a Polylith base in code and not config. But obviously it can be done in integrant too, but it’s aesthetics. I will experiment! Thanks.

I personally prefer Component over Integrant. While I appreciate the somewhat more "data-first" approach of Integrant, I feel it loses out on "simplicity" as it has several more extension points than Component's start/`stop` and I find scattering defmethod all over the code really makes it difficult to get a handle on what exactly is being executed (I dislike defmethod in general and use it very sparingly, and nearly always with all implementations in one file).

Mark, you could also consider not using Integrant/Component etc in your polylith components. If your polylith component has a lifecycle, you can for example just make a record out of it. The polylith base can then manage the lifecycle using Integrant / Component whatever.

@mark354, hey! As a co-author of a Polylith repo that launches quite a few systems (with different approaches/libs), I find that Integrant makes a perfect fit with it. The only thing that I’d keep in mind is that it makes sense to split your components (“keys” in Integrant terms) into two parts: 1. the init / halt! implementation functions go to a particular component (that can be used with any library, in fact, e.g. Component, Integrant, Donut Party System, Mount, etc.), 2. while the Integrant-specific multi-methods go to a particular base (the actual application or service) that is itself a system. This way you’ll be able to maintain an approach/library-independent abstract system component lifecycle-aware Polylith bricks.

This all makes a lot of sense. As I have migrated I’ve just copied in the multimethods into my polylith components but it felt incorrect to do so. Moving the orchestration to the base makes sense to me and reduces impact of any specific decision between component vs integrant vs anything else

Thanks all.