Clojurians Log v2

@seancorfield I replaced with org.slf4j/slf4j-nop {:mvn/version "1.7.25"} + some other changes that I was working on. You can find them in the latest commit (version issue-66.09 ).

Yes, that looks reasonable to me. As long as the code we write improves the readability and changeability, I think we should feel free to put implementing code in the interface. Often the right thing to do is to put all implementing code in another namespace than the interface, but sometimes it does make more sense to put it there. We should not just follow rules and instead do what we think is best for the health of the codebase, which this probably is a good example of (and if we change our mind, it’s easy to move the code to the implementing interface).

This is why I said it should not be a direct dependency of poly — only when you build the executable:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/Users/sean/.m2/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.13.3/log4j-slf4j-impl-2.13.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/Users/sean/.m2/repository/org/slf4j/slf4j-nop/1.7.25/slf4j-nop-1.7.25.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See <http://www.slf4j.org/codes.html#multiple_bindings> for an explanation.
SLF4J: Actual binding is of type [org.apache.logging.slf4j.Log4jLoggerFactory]

So you are still “breaking” other logging in people’s codebases.

There’s still something else interfering with my test’s logging though. I’ll keep digging and let you know. But you definitely need to remove that slf4j lib as a direct dep of poly — and add it in the contexts where you run the tool.