[phillord2]

It's a set of clojure code that I expect people to use in an interactive shell by, yes, calling methods. Whether people do that within an IDE, directly at a REPL or by running a script is up to them.

I'm still not understanding why I should perform major surgery on my tool for the sake of a logging library which is a transitive dependency.

Nor am I understanding why I should pass the error message that confused me on to downstream users. I'm happy to make the decision rather than sit on the fence.

[xg15]

My point is that "not passing on the error message" could make life harder for downstream users too, depending on who those users are. (Sorry if my reply was arrogant or harsh - I got burned by this in the past, that's why I'm telling it)

If you're developing a project and use SLF4J by yourself, and use a third-party-dependency that already includes a logger implementation, this dependency can override your logging and cause all sorts of havoc. This can be a frustrating and hard to find bug.

(I'd say the fact that this can happen at all is a design flaw in it's own, partly caused by Maven's way of dependency resolution, partly by SLF4J. But I don't see that changing in the near future...)

I think it's important to consider how your project will be used. if it's really just for exploratory use in a REPL/a few scripts, then including a logger is fine. If you think this project could be used in larger projects, you should consider leaving it as it is or restructuring.

If you do include a logger, leave a note about it in the documentation. This way, users can at least exclude it again if they have to.