Clojure Q&A - Recent questions and answers in tools.namespace

Answered: tools.namespace remove-node does not remove outgoing dependencies from :dependents

Mon, 20 Jan 2025 03:53:12 +0000

I don't actually know the original intent but the docstring you quote says "without removing it as a dependency of other nodes" which sounds like what it does?

Answered: tools.namespace no longer returns declared metadata on namespace

Tue, 30 May 2023 04:55:47 +0000

Logged as https://clojure.atlassian.net/browse/TNS-61

Answered: clojure.tools.namespace throws casting error when calling find-ns-decls-in-jarfile

Fri, 10 Mar 2023 16:36:22 +0000

created https://clojure.atlassian.net/browse/TNS-60

Thanks!

Answered: How to restrict namespaces reloaded by tools.namespace to only dependencies of a root ns?

Sat, 04 Mar 2023 22:36:00 +0000

Answered: Should tools.namespace find still cope with namespace-less sources?

Tue, 21 Feb 2023 20:52:43 +0000

Thanks for this report. Created https://clojure.atlassian.net/browse/TNS-59

Answered: Exposing namespaces that will be reloaded from c.t.n.repl

Thu, 29 Sep 2022 20:21:35 +0000

Created jira at https://clojure.atlassian.net/browse/TNS-58

Answered: Could tools.namespace refresh get more sophisticated directory/file filtering?

Mon, 09 May 2022 15:24:00 +0000

There is now a clj-kondo issue to try and solve this from that side.

Answered: tools.namespace does not recognise ns deps implied by data_readers.cljc

Fri, 06 May 2022 20:35:49 +0000

I think one important consideration here is that having a data_readers.cljc does not do anything to automatically load or require the reader function namespaces. Your program is still responsible for requiring the namespace that contains the reader functions before the point where you read tagged literals mapped to that reader function. This is often annoying for tagged literals in the source itself, and maybe something that should be changed, but that's just how things work right now.

Given that, the namespace containing the def implicitly depends on the reader namespace for it to be readable, and the correct thing to do is to make that dependency explicit in that namespace's ns definition. And if you do that, there is no "data_readers.cljc induced dependency", only dependencies already explicit in the namespace definitions and you will not have this issue.

Therefore, I do not think this is a feature that is needed by tools.namespace (given the current implementation of Clojure).

Answered: Resolution for bug TNS-6 in clojure.tools.namespace

Mon, 24 May 2021 18:19:22 +0000

Are you interested in becoming a contributor and submitting the patch? If so, please sign the Contributor Agreement and file a support request to get a jira account per https://clojure.org/dev/dev#_becoming_a_contributor.

If not, then I can't actually look at your patch, but perhaps you could describe the problem and solution and a contributor can write a clean patch.

Answered: Should tools.namespace.repl/refresh exclude code found in ~/.gitlibs?

Fri, 02 Apr 2021 02:12:45 +0000

It is a really good idea to set-refresh-dirs in advance. Examples, production-oriented scripts, drafted code, etc - none of those tend to be safe to require blindly (which is what (refresh) does when unconfigured).

Answered: Preventing `clojure.tools.namespace.repl/refresh` from loading namespaces that haven't been loaded before

Fri, 02 Apr 2021 01:54:34 +0000

Upon the very first call, it reloads absolutely all Clojure files on the classpath.

Correction: it doesn't reload ever ns in the classpath. It is limited to directories (as opposed to .clj files contained in .jar files, which also form part of the classpath).

Anyway, that's its behavior when a user hasn't performed set-refresh-dirs. tools.namespace cannot make a best guess of what the refresh-dirs value should be, so the best practice is to set it oneself intentfully in advance.

This is reflected in Sierra's reloaded template.

At the very least, it makes the first refresh call much slower than needed.

tools.namespace is aimed at programmers seeking an automated code-reloading, project-oriented workflow.

It assumes that you want to work with your project (as opposed to with an arbitrary set of scripts), and cannot guess which project namespace will be necessary first, or what will you do first (run tests, start a server?). So it loads every ns.

It's worth noting that a REPL session can last days, if not weeks. If something goes wrong, you can (clear) and start over.

I have some Clojure files on classpath that require dependencies that aren't available. That alone makes it impossible to use refresh.

This issue is entirely gone when using set-refresh-dirs.

Of course, the workaround assumes that each files has a proper ns form and doesn't create other namespaces.

That is a good assumption to do for every ns that lives under src, test. Arbitrary tooling can break on namespaces that fail to follow this de-facto standard.

Again, this is why set-refresh-dirs exists - to distinguish the 'main' source paths (src/, test/) from other directories containing examples, scripts, drafts, and such. It in fact dangerous to perform require over arbitrary namespaces in a given project (as those can be production-oriented scripts etc).

Answered: Would be nice if tools.namespace.find functions return file info in ns-decl meta

Tue, 05 Nov 2019 14:13:58 +0000

This is a duplicate of https://ask.clojure.org/index.php/8044/support-namespaces-as-strings-in-require-statements (jira at https://clojure.atlassian.net/projects/TNS/issues/TNS-51).

Or at least I think it is, please correct me if not.

Answered: How does tools.namespace.track/add is supposed to work?

Sat, 26 Oct 2019 16:26:26 +0000

Initially, everything needs to unload/load. This is because when refreshing, there isn't anything tracking code loaded time vs file modification time. So the initial load/unload is everything.

As reload runs against everything it will remove nodes from :unload as it goes.

I'm not sure what behavior you're expecting from this. But I would guess that initially you don't want anything to be in the unload/load lists. I would using assoc to set those keys to [].

Answered: Is it usual to require all application namespaces via tools.namespace?

Tue, 13 Aug 2019 01:17:54 +0000

As asked: "Is it usual to require all application namespaces via tools.namespace?"

No, definitely not "usual".

It's not particularly usual to have multimethod/protocol implementations spread across so many namespaces -- that are otherwise not required by code that uses those multimethods/protocols -- that a list of requires of them is particularly "noisy".

tools.deps has a number of provider implementations spread across namespaces but it requires all the built-in ones in the "entry point" namespace for other code that uses the library. See https://github.com/clojure/tools.deps.alpha/blob/860bc7e3e310380b3baf9b43b05d343f3ae812f6/src/main/clojure/clojure/tools/deps/alpha.clj#L17-L22 -- I don't know whether you'd consider that "noisy"?

If you really do have a "lot" of implementation namespaces that are not likely to be required by any other code, and therefore need loading somewhere near startup, then I would first consider creating an interim namespace that does the requiring and then just require that in your initial namespace.

If that still seems too noisy, I might consider using tools.namespace to automatically find and load just the implementation namespaces, assuming they follow an appropriate pattern. But I've never run across that need in eight years of production Clojure so far.

Answered: Java 11 and Tools Namespace

Thu, 01 Aug 2019 01:42:49 +0000

This is due to a known issue with a library java.classpath on which tools.namespace depends, which has been fixed and released, but in a later version of java.classpath than the one that tools.namespace currently depends upon.

I can create an issue to fix that in tools.namespace, but without waiting for a fix, you can explicitly add a dependency upon the later version of the java.classpath library in your project, and likely things will work for you with JDK 11:

org.clojure/java.classpath {:mvn/version "0.3.0"}

It is likely that in the projects you have seen where things are working, some other dependency you have requires a later version of java.classpath.

Answered: Show full path for circular dependency exceptions