Clojurians Log v2

The set of clojure.* namespaces that are loaded by clojure itself so they do not need to be required has changed in the past (but it has been a while). It is best to require whatever you use beyond clojure.core

I can understand that. Still seems like an incorrect warning to me, especially in a .cljc file, which limits how old a version of clojure can be supported.

Maybe we need a unique warning for clojure built-ins warning you "shouldn't rely on Clojure to always provide this namespace without a require"?

I don't think it's good practice to use a namespace qualifier without requiring it, regardless of whether it just happens to "always" be already loaded by the time your code runs... I think it's a perfectly reasonable warning.

Thanks for reiterating that. Still (not= good-practice correct-warning)

FWIW, it varies between -M -e and what is loaded by the time a bare REPL is up and running, so it's very much an implementation detail and not to be relied on.

I don't think it's reasonable to expect the average coder to know such gritty details as "it's an implementation detail". I opened this thread thinking it doesn't even deserve a warning, and have been corrected. But as someone who has not been coding in Clojure since it's inceptions, I still hold this deserves a warning unique from just "unresolved".

Are you arguing this linter should not be default on or this linter should not exist?

Given that (loaded-libs) changes across contexts, how is clj-kondo to know that an ns is already loaded? And how is this different to requiring some library ns and then using nses that ns just happened to require without explicitly requiring it yourself? I don't think clj-kondo can tell, in general, whether there's a missing require or not, when it finds an ns being used that you have not required.

I am kind of at a loss, clj-kondo is a linter, linters commonly encourage good style

I'm not arguing to quit warning. I'm arguing that clojure.* namespaces, which one would expect to load in on their own (but theoretically might not) need their own linter.

Create an issue on GH -- but I don't think clj-kondo can reliably tell what's loaded, even for clojure.* nses.

Since we started as a thread, I'm just waiting for agreement from borkdude that he's willing to implement it, or allow implementing it, or at least hammock the idea, before opening an issue.

My point is that clj-kondo can't tell whether clojure.something is loaded before it is used -- that's runtime behavior.

But it can certainly tell that it's clojure.something and I'm sure a list can be put together of which of those are usually loaded.

Essentially, I'm asking for more info, so that "I" (the next person to come along thinking the same) know this is not just an oversight in clj-kondo to be ignored, without needing to fix "my" own code.

I was curious so I checked earlier Clojure versions: • 1.0 and 1.1 only loaded clojure.main • 1.2 added http://clojure.java.io (unchanged in 1.3) • 1.4 added clojure.string • 1.5 added three more (unchanged in 1.6 and 1.7) • 1.8 added two more • 1.9 added three more (unchanged in 1.10, 1.11, and 1.12) That's just -e '(loaded-libs)' -- what you get in the REPL is different and what you get in a running program is different (more things are loaded by the implementation in the REPL than in running a program).

Should be based primarily on larger set from the repl, I think, for all the versions. Cover all the cases where a user might see that warning, but say "but it's resolving just fine".

If your code "satisfies" the REPL context, it might break when you run it for real, if you ignore the warning...

Yeah, which one might hope clj-kondo could save you from. Right?

Not if you ignore the warning because it's seems b.s.

Yeah. Wondering what happens in an uberjar context. Which contexts is it valid to rely on the namespace being loaded

The uberjar context has fewer nses loaded than the -M -m context, both of which have fewer than the REPL.

I like the idea of a linter around the typically loaded namespaces. Not just clojure.* since that would get edn and others. Have a way to disable it. But I would never disable this linter

@dpsutton Do you think folks can use clojure.edn without requiring it? (since you mentioned it) -- no peeking in the REPL or the source code! 🙂

No I don’t think so

Yup, you can.

today-i-learned

Here's the 1.12 list for an uberjar with a minimal main ns and -main fn: clojure.core.protocols clojure.core.server clojure.edn clojure.instant http://clojure.java.io clojure.main clojure.spec.alpha clojure.spec.gen.alpha clojure.string clojure.uuid clojure.walk

(as noted above, that's version dependent -- although it hasn't changed for a few versions at this point)

Since bork doesn't seem to be around right now, and I got at least 1 clear thumbs up, went ahead and filed it. https://github.com/clj-kondo/clj-kondo/issues/2460

Yes! While I may seem very "anti", it's always worth creating an issue for discussion with the maintainer (and other community members who might care).

Still glad I held off. Arguing about it moved me from a vague "this doesn't seem right" to a clear "this is what's wrong, and what to do about it."

Clarifying the problem statement is important...

replied in the issue

happy new year

happy new year to you too

Is this in the editor? Which editor?

(I ask because I use Polylith at work and it's all :local/root deps everywhere and I don't have this problem with clj-kondo and changes in VS Code)

Calva

It's inconsistent whether it fails. Can't give accurate frequency, but feels like around 90% of saves.

I can't remember having seen behavior like this before. Perhaps you can make a repro? Preferably using linting from the command line, so we can have the editor out of the equation.

I'll see what I can do. thx