Thank you for sharing your progress publicly like this. It’s been fascinating to follow along with your Polylith journey so far!

This thread can be of help 🙂 https://clojurians.slack.com/archives/C013B7MQHJQ/p1630498700026400

We use tags per project, and only deploy projects that have changed

oh cool, I’ve missed that thread somehow, thanks 🙂

I guess the brick’s src directory is the right place. Then you should be able to put it in the brick’s namespace, e.g. com.my-top-ns.my-brick.data-reader. Path: components/src/com/my_top_ns/my_brick/data_reader.clj .

Can data_readers.clj files even be namespaced?

https://clojuredocs.org/clojure.core/*data-readers* > When Clojure starts, it searches for files named 'data_readers.clj' > and 'data_readers.cljc' at the root of the classpath. Each such file > must contain a literal map of symbols, like this: > {foo/bar my.project.foo/bar > foo/baz my.project/baz}

Yeah, it looks like Clojure isn't loading data_readers.clj when I put it in the components/src/com/my_top_ns/my_brick/ directory

Okay. Maybe you can create an issue? The solution could be to allow data_readers.cljfiles to be put at the root without getting the warning. The good thing is that you only get a warning, so it will at least work till this is released. It is an easy fix, so I could prioritise it.

I was thinking about one thing. What happens if you have two data_readers.clj in different components? Then the class loader will only find one of them? But maybe there will always only be one?

The docs suggest that the Clojure reads them all. > Each such file much contain...

Yep, I can confirm that Clojure loads all the data readers. And user-defined reader tags have to be namespaced, so if each data_readers.clj is tied to a brick there's no risk of a name collision.

Okay, but does it mean that you don’t have to put them at the root, and instead can put them in each brick and get rid of the warnings?

It has to be src/data_readers.clj or resources/data_readers.clj -- it has to be at the root of a classpath entry.

But, yeah, putting them in the bricks that have the functions that the data readers need seems like the right solution to me -- and just ignore the poly check warning until @U1G0HH87L makes that go away 🙂

data-readers is a special-case namespace for Clojure and JAR-building tools have to know how to handle those files too (they have to read them as EDN and merge them when building JAR files!).

And data_readers.cljc is also supported by Clojure.

> It has to be `src/data_readers.clj` or `resources/data_readers.clj` -- it has to be at the root of a classpath entry. This is splitting hairs, but is data_readers.clj /`data_readers.cljc` more of a resource or more of a source file?

Since it's an EDN file mapping reader tags to invoked functions, I guess it's more of a resource.

I thought it is allowed to have resources without namespaces e.g. resources/data_readers.clj within a component or base. Do I remember correctly @U1G0HH87L?

Yeah, it's kind of weird that it's a .clj/`.cljc` file at all really. But that would lean me toward src since it "looks like" a code file...

> I thought it is allowed to have resources without namespaces e.g. `resources/data_readers.clj` within a component or base. Do I remember correctly @U1G0HH87L? I don't think it matters what you call the folder - test, resources, src, foo, bar, baz. The Polylith tool will find data_readers.clj and issue a warning.

Right, it complains because it thinks it is a code file. You can have resources without "namespaces" if poly doesn't think they look like code files 🙂

I believe it’s wrong that Polylith thinks something under resources folder is a source file right? @U1G0HH87L, maybe this is a bug or intentional?

It feels like it’s quite important that we get this right. As @U04V70XH6 suggested, the natural place is maybe to put these files under the src directory, so that we can work with them in the IDE as source code (Cursive didn’t recognise data_reader.cljas code when I put it in resources ). The other issue is wether we should allow people to add source code in resources. I guess this is fine, if the code can’t be used as source code (which I think is the case) but I’m not sure (other people may know this, and can answer in this thread). I think we should continue checking all other directories, not just src and test for .clj and .cljc files to make sure they don’t live outside the top namespace (so that we can’t add e.g. a src2 directory and put code at random places there).

To answer @U0295UQ75FG. It is allowed to put resources anywhere under a component’s resources directory, but it’s recommended to put it in a directory with the same name as it’s interface(which in most cases are the same as the component name), to avoid naming conflicts, e.g. components/mycomponent/resources/mycomponent/my-resouce.png. And yes, right now, the poly tool checks all directories under a brick’s directory, regardless of the name of the directory, e.g. test, resources, src, foo, bar, baz.

I haven’t used data_readers before and don’t know much about them. However, based on what is written above, they are not sources but resources that is read as edn. In that case, I don’t think they should be placed under src directory.

I haven’t used data readers either, but you have a good point there.

I don't think there's much of a consensus as to where people put data_readers.clj(c) files -- under resources or under src -- but I suspect the .clj(c) suffix is mostly to trigger Clojure syntax support in editors, on the assumption that support for .edn is less widespread, and Clojure support would allow go-to-source on the actual reader symbols. If Cursive doesn't recognize them as source code under resources, that's just a quirk of Cursive and not at all reflective of editors in general, nor any sort of "guidance" on where such files should live.

TL;DR: poly check just needs to know that data-readers is a "special" namespace that won't (can't!) follow Polylith rules and just exempt it from top-ns checking. That's the smallest, simplest change that solves the problem, without changing any other "rules" that Polylith wants to follow.