This is discussed around once a month here. I prefer the simplest approach of either creating the vars by hand or by not doing it at all.

You can just do in 'com.bar.baz' (:require com.bar.baz.x :refer :all) Or do you talk about making the vars available outside of com.bar.baz? To clients ? Then you could use clojure.core/load and just load the other files as part of the same namespace but put the code into separate files only I have done this in my game engine, see here: https://github.com/damn/gdx/blob/e0d767284f7d2c81be6584ed885f1198a16ca5a2/src/gdx/graphics.clj#L29 Not that those are not separate namespaces, just separate files for reason of logical separation. `(load "graphics/colors") (load "graphics/shapes") (load "graphics/images")`

I just came up with another solution. I didn't see it anywhere yet but as far as I can see nothing speaks against it ? `(defn intern-public-vars [from-ns into-ns] (doseq [[symbol var] (ns-publics from-ns)] (intern into-ns symbol @var)))`

Any static code analysis will not work with the above. It also loses var metadata. Potemkin has something like that, with workarounds for some things, and it has been in use for quite a long time - and it's still a problematic solution. But again - it's been discussed time and time and time again. Better use the search function and go through all the previous discussions.

You are referring to the intern-public-vars or the use of load? I think clojure itself also used load.

I was mostly referring to the former but load also has issues. Don't recall exactly but I think tooling- and REPL-related. Clojure's usages of load are ancient, well-known, not something that will change, and not something that you use with REPL.

Then it's a tooling problem ? We have to improve our tools to understand load. Maybe some metadata in the namespaces or we could extend the namespace form itself

Please use the search function. The exact same arguments have been repeated many times. There is zero reason to reiterate anything.

My personal use of load works fine, although repl doesn't work but then I use do refresh-all from tools.namespace

@U0ALH6R89 I was able to achieve this using a combination of in-ns and load as you suggested. https://clojurians.slack.com/archives/C053AK3F9/p1676998189746859?thread_ts=1676959183.204429&cid=C053AK3F9 But as @U2FRKM4TW says, this does have issues. One thing I noticed is that when doing a "Go To Definition", it seems to jump to one of the "helper files" instead of the "main file", and in certain cases it doesn't work at all.

It is interesting because if you try "Go To Definition" on the clojure.core namespace it goes to clojure.core-print instead.

The nice part about martian is that you are not married to a particular HTTP client. In fact, many clients are supported OOTB. I do not recommend using http-kit at all since there are much more mature solutions out there such as clj-http and hato , both of which support HTTP/2 and Cookies — neither of which are well supported by the http-kit client

> Currently got an issue with the practically project templates Where did that 2023.07.14 part come from? While it might be the version of the project, the correct tag, according to the list of Git tags, is 2023-07-14.

@U2FRKM4TW John has just fixed the issue. 🙂

Ah, nice!

@U0479UCF48H Oh yeah, I remember martianfrom nubank k8s-api. Good points raised. 👍 Would be happy to get away without static code generation.

First time seeing Martian. This looks great!