Fork me on GitHub

Anyone using amazonica ( and know what clj-kondo should be configured to lint as the various functions it reflectively generates?


I think for that lib I would just give up and add the namespace to :unresolved-namespace {:exclude ...


:unresolved-var {:exclude []} 🙂

👍 2

If you care, you could also use the mock feature of clojure-lsp


I'll have a shifty when I get some time 🙂


Thank you! :)


FYI, we are using amazonica in some places but we're looking into migrating to cognitect's aws-api. Amazonica is very macro-heavy and that has caused us a bunch of problems unfortunately... (not being able to inspect the source or easily lint it are two of them) Happy birthday Mr borkdude! 🙂

🎂 2

slightly off topic: just fyi, aws api doesnt support SSO logins on local machines and it quite a deal breaker for us, still sticking to amazonica just for that for things that need to local dev/testing

lispyclouds13:02:54 is open forever with pretty much no interest from them for a fix


will try it out


(probably, as it doesn't aspire to have features beyond aws-api, I think)


We don't need SSO logins for now but that's good to know, thanks. Given that cognitect maintains the library have you asked them here? I'm sure a PR would go a long way too Btw, this is what they say on their page: > The open source repositories collected here are experimental works in progress by Cognitect. We make these projects available in the hope that you find them useful. These projects are provided without support or guarantee of their continued development. The contribution model and license vary per project, please check each repo for details. so they're not really committed to updating the repo


> I'm sure a PR would go a long way too they dont do PRs though. wouldve been happy to fix it.


they dont accept any external fixes in that repo in general it seems


My experience is that pinging the maintainers (@U0ENYLGTA) in the respective channels often helps moving issues further

👍 2
👋 2

> they dont accept any external fixes in that repo in general it seems Oh, I see, that's too bad... For what it's worth I've upvoted the issue, let's hope it moves more quickly...


Good news! We are interested in a fix and are working on one. We haven't put anything in the ticket yet because we can't commit to a timeline, but we're adding support for sso in general and CodeCatalyst in specific.

🙏 2
💜 4

awesome! thanks a lot! 🙏:skin-tone-5: really really excited for this! 😄


Me, too! And I appreciate the frustration of these issues sitting around for so long. We seem to have some momentum right now within Nubank, so, while I can't promise anything, I'm optimistic that we'll be addressing issues more regularly now. Stay tuned!

❤️ 6
👍 2

this is sincerely appreciated! thanks again. love the lib and this would make it perfect!


Oh, perfection is a long way off 🙂 But I'm glad to know it's helping you!

gratitude 2

You see, pinging helped :)


And all of that in the clj-kondo channel due to some issues with amazonica linting 😆

😎 2

By the way @U0ENYLGTA I have to say I love the design of aws-api. Being able to list the available operations with (aws/ops client) at runtime might be a simple idea but it is mind-blowing and immensely useful. I'm using it all the time.


You can thank @U06UY677Y for that 🙂

🙏 2

data oriented programming FTW

🎊 6

I'm not a particular fan of amazonica personally, much perfer the cognitect libraries, but <shrug> gotta work with what I have been given


Good 'tho, that I can switch off the warnings 🙂

Braden Shepherdson22:02:31

is there a convenient way to see what kondo is seeing in an expression/file? I'm having issues with :macroexpand and :analyze-call configuration for a macro and getting puzzling lint errors. I'd love a command that would tell Kondo to print its massaged view of the file to stdout, or something similar.


You can use println in those hooks to print the new node before you return it


And then call clj-kondo from the command line to see the printed result

Braden Shepherdson22:02:51

ah, that works decently well. it's illuminated a few more steps on the way for me.


You can also develop hooks in the REPL, so you can inline def the vars and inspect them

Braden Shepherdson22:02:56

Metabase is rigged up for that, yeah.

Braden Shepherdson22:02:35

does Kondo's macro system transform regex literals #"\s" into (re-pattern "s")? I can't find where that's coming from, but that's the root issue in this case.


I think that's behavior from rewrite-clj


perhaps it contains a bug, could be


$ bb -e '(rewrite-clj.parser/parse-string "#\"\\s\"")'
<regex: #"\s">
$ bb -e '(rewrite-clj.node/sexpr (rewrite-clj.parser/parse-string "#\"\\s\""))'
(re-pattern "\\s")


This only happens with the :macroexpand hook since that relies on calling sexpr on the input nodes

Braden Shepherdson22:02:41

it looks like the escaping is being dropped somewhere, yeah.

Braden Shepherdson22:02:04

by the time it prints out from the :macroexpand, I'm seeing (re-pattern "s")

Braden Shepherdson22:02:29

but it does seem like rewrite-clj is doing the right thing, as in your experiment above.


clj-kondo has an older version of rewrite-clj that might be behind in this regard. it's available as clj-kondo.impl.rewrite-clj.*


in the REPL


user=> (clj-kondo.impl.rewrite-clj.node/sexpr (clj-kondo.impl.rewrite-clj.parser/parse-string "#\"\\s\""))
(re-pattern "\\s")


looks correct to me (other than that the re-pattern symbol should be fully qualified)

Braden Shepherdson22:02:28

yeah, it LGTM too. but the input to my :macroexpand macro is already broken.


if you can submit a small repro (smaller is better) with a macroexpand hook, I'll take a look later. it's getting late here. The input is already the result of sexpr since the input are regular s-expressions with macroexpand

Braden Shepherdson22:02:11

sure, I can find a basic repro and file a bug. I need a repro for that format syntax checking bug too. thanks for your help debugging this.

👍 2
Braden Shepherdson23:02:47

curious! those two bugs are related. I was playing around with the format string issue. (format "%s \"%s\"" "foo" "bar") is no problem, but (wrapper (format "%s \"%s\"" "foo" "bar")) (using the same clone of do macro from the gist for the regex bug) gives the error (`Format string expects 1 arguments instead of 2`). so gut instinct is that strings (including the string in (re-pattern "\\s")) are getting unescaped somewhere in the in the rewrite-clj pipeline kondo uses for macros.

Braden Shepherdson12:02:11

am I reading it right that because this is a Clojure syntax RuntimeError, not a linter error, I can't avoid it with configuration settings? if that is the case, I can sit on the original change for a few days but I'm not sure how long new releases of rewrite-clj and clj-kondo are likely to take.


I think this is a bug in rewrite-clj which I submitted a PR for: But one of the library tests are failing with that change, so I'll also have to dig into this.


clj-kondo doesn't depend on a new version of rewrite-clj being released since it has its own internal fork, to which I'll apply the same change once it's confirmed that this bug + fix makes sense

Braden Shepherdson12:02:07

okay. I think on further investigation I can work around this by making sure no regex literals are found inside :macroexpand macros by putting the regex in a def.


So I pushed a workaround on clj-kondo master after investigating options all day... There's also a pending issue / PR in rewrite-clj proper but I'm still working on that with @UE21H2HHD - the exact details don't really matter in clj-kondo so I was able to do the workaround there for now

Braden Shepherdson19:02:20

cool, thanks. I've been following the several rewrite-clj PRs.