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

👍 🙂

:unresolved-var {:exclude [amazonica.aws.s3]} 🙂

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

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

btw: 🎂

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! 🙂

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

https://github.com/cognitect-labs/aws-api/issues/182 is open forever with pretty much no interest from them for a fix

Does https://github.com/grzm/awyeah-api have the same problem?

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. https://github.com/cognitect-labs/aws-api#contributing

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

> 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.

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!

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!

You see, pinging helped :)

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

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 🙂

also inspires the design for https://github.com/lispyclouds/contajners

data oriented programming FTW

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 🙂

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

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

See this section: https://github.com/clj-kondo/clj-kondo/blob/master/doc/hooks.md#tips-and-tricks

Metabase is rigged up for that, yeah.

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

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

is it?

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

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)

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

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.

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.

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: https://github.com/clj-commons/rewrite-clj/pull/215 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

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

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