Clojure can handle that natively? That’s pretty cool!

clj-kondo uses namespace-munge to detects if the filename corresponds to the namespace name:

user=> (namespace-munge "foo->")
"foo_>"

that it works, might be accidental, since the reverse operation is probably just the general demunge

user=> (doc namespace-munge)
-------------------------
clojure.core/namespace-munge
([ns])
  Convert a Clojure namespace name to a legal Java package name.

To play it on the safe side, I'd just name the file condp_thread or so

having > in filenames can be awkward in bash and I don't even want to know what happens in Windows :)

Oh, weird. namespace-munge and munge do not match?

no, there are some subtle differences, I can find the related clj-kondo issue for you

https://github.com/clj-kondo/clj-kondo/issues/1791

but if your hook worked, this is actually a bug in the clj-kondo SCI env, since it should also use namespace-munge for looking up that file :)

https://github.com/clj-kondo/clj-kondo/blob/a6c31e4aa4a37c01e8aa3975ccb1c498b9761e0c/src/clj_kondo/impl/hooks.clj#L64

and I think I have this bug in babashka then too

I guess I got the impression from earlier discussions and examples that a hook for x.y.z/abc needed to be in hooks.x.y.z.abc/abc but I gather that's not true? What are the constraints on the namespace/function name for hooks?

you can make up any namespace name in the local .clj-kondo directory, as long as the namespace name corresponds to the filename.

hooks. is just a convention

clj-kondo has a kind of classspath. the local .clj-kondo directory is added to that classpath, as are all two-level deep directories: acme/lib

OK, so I don't need a separate file for each hook function? If a ns in my code has multiple macros that need hook definitions, I could have hooks.whatever/something.clj and that could contain all the hook fns for those macros?

correct, you can stuff as many hook functions in the same file as you want

Cool. I can do quite a simplification of our hook setup then 🙂

@U04V70XH6 would you consider adopting the .clj_kondo extension for hooks? I've come across a https://github.com/clj-kondo/clj-kondo/issues/1685 related to having hook code in .clj files.

@U08BJGV6E I'm talking about hooks within our monorepo at work, to handle macros in our own code, or 3rd party libraries we use that don't have clj-kondo support.

oh, I misunderstood then. I was under the impression some of these were for your OSS projects

apologies

I'm puzzled by your issue: I don't have the .clj-kondo folder on my classpath so I can't see how an IDE would ever confuse the hook code with actual Clojure code?

And even if .clj-kondo is on your classpath, the ns would be different and would not be something any of your code nses would ever require -- so, again, how on earth can be IDE get confused about that?

It isn't normal for .clj-kondo to be on the classpath and my issue isn't about that. The problem comes out when a library distributes its own clj-kondo hooks (among its resources), and that library is used by a consumer via a git dep.

a quick repro case is

clj -Srepro -Sdeps \
 '{:deps {org.clojure/tools.namespace {:mvn/version "1.2.0"} seancorfield/next.jdbc {:git/url "" :git/sha "24bf1dbaa441d62461f980e9f880df5013f295dd"}}}' \
 -M -e "((requiring-resolve 'clojure.tools.namespace.repl/refresh-all))"

Oh, you mean like this: https://github.com/seancorfield/next-jdbc/tree/develop/resources/clj-kondo.exports/com.github.seancorfield/next.jdbc/hooks/com/github/seancorfield

yep

Heh, yeah, well a) don't use c.t.n.r and b) don't use Cursive 🙂

There's a tools.build repro as well 🙂

since you prefixed that with "hooks" there is no problem

Well, that's what I thought @U04V15CAJ so I'm surprised it's a problem...

well maybe there is, if c.t.n.r tries to load every .clj file there is on the classpath, but why would it do that, if nothing else refers to it?

that's just how c.t.n.r works, I asked about it https://ask.clojure.org/index.php/11434/could-namespace-refresh-sophisticated-directory-filtering but core aren't interested in changing that

c.t.n.r is just broken (in many ways). I wish it didn't exist 😕

According to Alex: But why are those in :paths? The whole meaning of :paths is "paths containing source to be put on the classpath". Seems like these source files should not be there if they are not source.

(referring to hook code in resources)

@U04V15CAJ To be clear, clj-kondo will find an import foo.clj_kondo as a hook in that resources tree (as well as bar.clj)? So I could change them and it would all still work? (that extension is news to me)

@U04V70XH6 Yes, this was implemented to solve this c.t.n.r problem

here's a https://github.com/clj-kondo/clj-kondo/blob/master/doc/hooks.md#compatibility-with-toolsbuild-compilation in you're interested

@U08BJGV6E Feel free to create issues on any of my OSS projects you use that have hooks in resources and I'll make the change next time I'm working on them...

next.jdbc may be the only one?

Thank you Sean, will do. That's the only one among yours where I came across it

And apologies again for hijacking the discussion

I just renamed it, and it is the only hook in any of my projects as far as I can see.

Currently, the only other unreleased change in next.jdbc is a small doc example so it may be a while before I release an update for that.

Thanks a bunch. Since the problem only comes out when referring a lib via git coordinates, it's already fixed

> Since the problem only comes out when referring a lib via git coordinates Why is that?

Yeah, that surprises me since the JAR files contains that same file/path:

655 Fri Nov 04 22:22:36 PDT 2022 clj-kondo.exports/com.github.seancorfield/next.jdbc/hooks/com/github/seancorfield/next_jdbc.clj

Because clojure tools differentiate between namespaces coming from a directory path vs a jar path

And git deps end up as directory paths

So maybe that was the root problem that should have been fixed ;)

Well at least ctnr and toolsbuild do

Well, Alex's comment overrides that I think

He basically says if a .clj file isn't to be loaded it shouldn't be on the classpath

And I wasn't successful in convincing him otherwise

I think compiling all namespaces, unrestricted, is usually a bad idea.

better be explicit about all entrypoints (which is usually just one)

I've had problems with this in both lein and tools.build with duplicate compiled namespaces + graalvm native-image and since then I always use an explicit list

deps-new has a bunch of .clj files in resources because they are templates for generating new projects -- but they are mostly illegal Clojure code and the ns in particular is not a valid symbol... but almost no one would have deps-new on their classpath while working on other stuff 🙂

(`clj-new`, boot-new, and lein new code all do the same -- and those .clj files are in the codebase, not even just restricted to resources)

I'm with you, I tried to phrase something like this at https://ask.clojure.org/index.php/11434/could-namespace-refresh-sophisticated-directory-filtering?show=11880#c11880

Alex responded to it

And his suggestion was to use a different extension

Which is why I created the kondo issue in the end

I'm reminded of https://corfield.org/blog/2018/04/18/all-the-paths/ wherein I examine how different tools deal with different "types" of paths -- and Leiningen in particular had :source-paths and :resource-paths (Boot also had these two keys but they meant different things of course).

haha yes, I could never figure out what boot meant with which key

https://github.com/seancorfield/deps-new/issues/39 -- for "completeness" on this topic 🙂

Nice article, Sean. In the end it all comes down to what is on the classpath at runtime.

Using :cfile, you can just load a file with kondo’s normal output