Share your thoughts in the 2024 State of Clojure Survey!

Welcome! Please see the About page for a little more info on how this works.

+1 vote
in tools.namespace by

We have to require namespaces with side effects like multimethod or protocol implementation.
So we have a lot of noisy require forms in one initial namespace.

Is it better to use tools.namespace for require all app namespaces?

1 Answer

+2 votes
by
selected by
 
Best answer

As asked: "Is it usual to require all application namespaces via tools.namespace?"

No, definitely not "usual".

It's not particularly usual to have multimethod/protocol implementations spread across so many namespaces -- that are otherwise not required by code that uses those multimethods/protocols -- that a list of requires of them is particularly "noisy".

tools.deps has a number of provider implementations spread across namespaces but it requires all the built-in ones in the "entry point" namespace for other code that uses the library. See https://github.com/clojure/tools.deps.alpha/blob/860bc7e3e310380b3baf9b43b05d343f3ae812f6/src/main/clojure/clojure/tools/deps/alpha.clj#L17-L22 -- I don't know whether you'd consider that "noisy"?

If you really do have a "lot" of implementation namespaces that are not likely to be required by any other code, and therefore need loading somewhere near startup, then I would first consider creating an interim namespace that does the requiring and then just require that in your initial namespace.

If that still seems too noisy, I might consider using tools.namespace to automatically find and load just the implementation namespaces, assuming they follow an appropriate pattern. But I've never run across that need in eight years of production Clojure so far.

...