Clojurians Log v2
babashka
Hey friends, we've kind of had a debate of silly importance on my team. I noticed how we tend to name our babashka scripts using dashes in the name. And then I noticed that kondo complains that the filename is not conventional for Clojure namespaces. My initial point was "if we ever decide to start reusing some code ... afaik you can't (require 'some-script)" if the filename is "some-script.clj" (it has to be some_script.clj). Counter-arguments are: • These are command line tools (sorta) • Unix philosophy, "apt-get", "docker-compose", "clojure-lsp", etc. - naming convention is for dashes • This is YAGNI and If we need ever to share functionality in a new script, it's better to move it into a library that is then referenced by both I personally like the aesthetics of dashed names and agree with my colleagues, but I also think my initial instinct wasn't wrong either. I wonder what your thoughts on this?
I don't really have a strong opinion on this, you can easily silence the warning with an ignore hint
kondo just compains because "on the classpath" this is a problem and kondo doesn't know that a script isn't on the classpath
Hello folks. If anyone has time and interest to https://github.com/cognitect-labs/aws-api/pull/273, we are adding babashka support to aws-api.
Hey @scottbale - happy to take a look. Are the maintainers of aws-api ready to take on bb compatibility?
or wait, you are a maintainer, right?
I am, yes 🙂
awesome!
And @marcobiscaro2112 too
That's great. Do you have any specific questions? Since you have a test suite and the tests pass, that's already a good sign I guess - that's usually what I go by first
No specific questions, we just want extra sets of eyes in case we missed anything or didn't think of some thing(s).
what's this about?
babashka uses a different thread to interpret the code, and the test that spits a cognitect_aws_http.edn and tries to create a new client was failing.overall PR looks good to me!
> what's this about? There's a lot more context in the issue that @marcobiscaro2112 linked to in that same comment: > A bug similar to https://github.com/cognitect-labs/aws-api/issues/265 was probably lurking here. But tl;dr is that aws-api would sometimes experience resource file loading problems if the classloader that was used to load the resource did not have access to the resource. So we had written this utility https://github.com/cognitect-labs/aws-api/blob/main/src/cognitect/aws/resources.clj to have better control over what classloader was used, and Marco found this additional place that we need to use it.