Fork me on GitHub
Joshua Suskalo17:09:54

Continuing from #tools-deps, where should I look to see about integrating with clj-kondo's analysis to get information out of vars?


@suskeyhose Let me get back to you on that in 15 minutes or so

Joshua Suskalo17:09:48

So I'm taking a peek at the analysis folder and it looks like only specific metadata is exported, and for my usecase I'd need the :style/indent metadata to be exported as well. Possibly a very small change. In any case I need to keep reading.

๐Ÿงก 2

@suskeyhose This is correct. But! There is an issue to collect arbitrary metadata and the fix for this is pretty easy, so perhaps you could provide some input and we can finally implement this.


I would be ok with just adding all metadata on a :meta key or so, when providing an option. The only "danger" is that metadata contains stuff that isn't readable as EDN or so.

Joshua Suskalo18:09:05

Ah, I see, since the data is passed over stdout it could cause issues.


well, clj-kondo is also available as a JVM library

Joshua Suskalo18:09:27

Right, that's what I'd want to use it as.


but it'd be nice if we supported both use cases at once: the EDN output should preferably be valid.


And the most secure way to do that is to just provide values as strings perhaps


using pr-str


OR we could make the selection of metadata optional (like in the issue) and then any EDN errors are the problem of the caller.


or we could choose to only export metadata with keywords as keys and constants as values

Joshua Suskalo18:09:01

I think having the :var-meta key like in the config is valid, and make it so just having true for it will return everything.


Note that this is valid: ^{(+ 1 2 3) (+ 4 5 6)}


that's what I'm thinking of


those cases are rare, but they do exist


so if the metadata has ^{:foo "bar"} then we'd export :foo "bar" but when it's :foo (+ 1 2 3) we don't, for example

Joshua Suskalo18:09:24

I think a valid constraint to put on it for now is to only grab the constant keys and values, and provide nothing for these dynamic ones, with the potential in the future that these may be added.

Joshua Suskalo18:09:21

Just entirely excluding these dynamic ones would help prevent breaking changes by leaving the possibility they're added later, without giving in the meantime a quoted version of it for people to depend on.


I think attrs would need an extra :meta key on which we do some processing before we add it to the analysis, if the option {:var-definitions {:metadata true}} is given, I think

Joshua Suskalo18:09:14

I think that would solve all the needs that I have, being able to start with the -T classpath with just . and my own dependencies on the classpath, and then using kondo to get all the metadata to generate the config file. Are there any other hangups I gotta be aware of before I start planning out my tool properly? Like having to figure out how to procure deps or something for kondo to lint them? Or will I be good just using's facilities for starting a clojure subproces to get the classpath with a set of aliases?


you can just pass the classpath into :lint ["the-classpath"]


@suskeyhose Would you like to have a stab at this?


It would also be interesting to see how many times the metadata is dynamic

Joshua Suskalo18:09:23

Yeah, I'll take a look at it tonight to see what I can get going.

Joshua Suskalo16:09:32

Okay, so I'm looking at this today @borkdude, and it looks like the line you pointed me to will allow a meta key to come from whatever is passed to reg-var!, so does that mean the rest of this implementation is to just go through all the usages of reg-var! and make them include metadata? It seems like that's the obvious direction to go.


yeah I think so

Joshua Suskalo16:09:49

Yeah, so there's the namespace/reg-var!, and there's analysis/reg-var!, and it looks like the namespace one is the only one used, and it calls to the analysis one, so I just gotta update the namespace one I think.

Joshua Suskalo16:09:56

'cause that already gets the metadata

Joshua Suskalo16:09:41

Hmm. There's a lot of metadata in there that's coming from clj-kondo and not from the original var. Is there a way to select just the stuff coming from the source?


hmm, like what for example?


I'll be back after dinner

Joshua Suskalo16:09:00

Actually I think I figured it out

Joshua Suskalo17:09:38

This is still a "draft" PR, but I'd love to know if this is the right direction, or if I need to be doing something drastically different. I'm thinking then I can have the analysis/reg-var! do the actual filtering of which meta values are allowed, so that no code changes are needed elsewhere if we expand which kinds of meta are allowed.


Yep, that's going into the right direction. Tests are the next step I think


Would be possible to clj-kondo correctly understand a var imported from potemkin and avoid unresolved-var lint?


clj-kondo already has built-in support for potemkin


Hum, we have this lib at nubank that uses potenkim a lot, and when using the vars from its api, I'm getting unresolved-var :thinking_face:


Repro welcome


I'll try to build a repro!


I found the time to repro the issue in a separated repo/branch :) More details here:


oh nice, I didn't know midje had clj-kondo exports


oh yeah, I merged that last month ๐Ÿ˜…


thanks for the repro. I think it should work but I don't know why it doesn't


hopefully I'll find some time to find out next week or so


or if you beat me to it...


The relevant code is in clj-kondo.impl.analyzer.potemkin


cool! I can try to debug tomorrow :)


ah, it seems the potemkin code isn't hit at all somehow

๐Ÿ‘€ 2

oh I see, I think it currently only supports potemkin syntax with some vector or so


and not a single symbol


So this works:

(ns clojure-sample.api
   [potemkin :refer [import-vars]]))

 [ some-func])


so I've done the debugging, I'm sure the fix is pretty easy now


I'll past this info in the issue


oh, really good catch!


I tried and it works indeed :)


there is this lib at nubank that uses a lot of import-vars with full qualified symbols


I think it will be a small change

๐Ÿ™ 2

for clj-kondo


I imagine that is just make clj-kondo lint this other way of import-vars I think right


yes, check if the thing is a symbol and act accordingly


So this is the code:

(defn analyze-import-vars [ctx expr]
  (let [ns-name (-> ctx :ns :name)
        import-groups (next (:children expr))]
    [{:type :import-vars
      (for [g import-groups
            :let [[imported-ns & imported-vars] (:children g)
                  imported-ns-sym (:value imported-ns)]]
        (do (doseq [iv imported-vars]
              (let [iv-sym (:value iv)]
                (prn :reg-var ns-name iv-sym expr {:imported-ns imported-ns-sym
                                                   :imported-var iv-sym})
                (namespace/reg-var! ctx ns-name iv-sym expr {:imported-ns imported-ns-sym
                                                             :imported-var iv-sym})))


instead of destructuring in the let, first check if it's a fully qualified symbol token


and then set imported-ns and imported-vars to that


else leave it like it is


so g can be either a vector or fully qualified symbol


Makes sense ๐Ÿ‘ I'll try to fix that and let you know, thanks for the explanation


Merged. I will make a small tweak, but nothing major.


One thing is, I would use qualified-symbol? instead of qualified-ident. Is there a reason you chose the latter?


yes, I didn't know about the former ๐Ÿ˜‚


I see, the ident checks for keyword as well while the other checks if it's a symbol only


teamwork ๐Ÿค

๐Ÿš€ 2

oh that makes sense indeed, good catch

Joshua Suskalo19:09:07

With regards to the dynamic metadata stuff, is there anything that'd get in the way of checking if all the vars used in the definition are from clojure.core and then evaluating it with sci? I figure an eventual goal for this kinda thing would be to get something that's basically like constexpr evaluation that would just recursively check vars for sci compatibility and then eval them. Although for clarity, I'm not looking to implement this at all for the part I'm looking at tonight. I still want to stick to filtering metadata to constants.


> is there anything that'd get in the way of checking if all the vars used in the definition are from clojure.core and then evaluating it with sci? yeah, I think you can do that, unrelated to the metadata feature I think


also some vars like clojure.string, etc are in sci


so as long as the program is pure Clojure, it should mostly work

Joshua Suskalo19:09:10

Fair enough. That'll be something that I might think about in the future once the basics of general metadata are into analysis

Joshua Suskalo19:09:42

Although at that point it might be worth just putting it into a tracking issue to see if there's interest in it before the work gets put in.


why would you eval the code, what's the goal with that?

Joshua Suskalo19:09:20

to get ^{(+ 2 2) (+ 4 4)} metadata working

Joshua Suskalo19:09:23

Like you mentioned before


oh right :)


I really do think these are rare cases though, so perhaps some exploration would be good to see often this occurs

Joshua Suskalo20:09:01

Yeah, that's why I was thinking about a tracking issue to see for demand


just evaluating random expressions isn't safe to do even with SCI, e.g. you can have (defn ^{:foo (range)} dude []) so I wouldn't recommend it


in the case the metadata isn't a constant, we could also just stringify it


but leaving it out for now seems also fine

Joshua Suskalo20:09:47

I think leaving it out for now is the best choice because it leaves us many options for what to do with it in the future.

Joshua Suskalo20:09:40

I'd rather provide something for 80% of cases, and for the 20% provide nothing, than provide something for 100% of cases with a potential for breaking changes to 20% of it.

Joshua Suskalo20:09:00

(although obviously the actual percentage of this kind of thing being uses is lower than that)