Clojurians Log v2
clojure
I am not quite sure where to direct this, so I'll try starting here: there is a homebrew package for Clojure, which I am very thankful for 🙏. However, it seems to hard-require java 26. I can't use Java 26, because I build my releases on this machine, and production servers use LTS releases (so, 25). This is why I have openjdk pinned to 25.0.2 on my machine and I have to continue using 25 until the next LTS release. But this means that homebrew now refuses to upgrade clojure and leiningen packages. With errors. I don't think Java 26 should be a hard requirement? Last LTS release should be fine?
You should use brew install clojure/tools/clojure to install Clojure.
> This tap is the source of the official Clojure brew formula (not the homebrew-core formula). The formulas in this tap and homebrew-central are similar but not identical. In particular, the homebrew-core formula depends on and attempts to update to the latest version of Java. Clojure itself does not require that and the formulas here simply assume you have (somehow) installed Java and put it on your path; they will not install Java for you.
Homebrew-central is quite pernicious with its "always latest" policy. :(
To avoid this kind of "need to install x, y and z on every laptop" I would advise to use a container for building and/or development. Simple way is to start using VS Code devcontainers and define the dependencies in the Dockerfile. Thus it becomes quite straightforward to avoid version drift and avoid the local installation hassle.
We build our deployable units inside VS Code devcontainer in order to avoid this exact problem.
@p-himik Thanks, this works. I didn't know about this! Much appreciated. @jussi.mononen I use containers for plenty of things and I used to use them for builds, too. But they introduce complexity and slow me down. I only have one development machine, it might as well be my container 🙂
Also, I think I didn't mention it: I don't actually use the clojure installed via homebrew for building releases at all — it's just that I want to have it in the system, and I don't want it to force me to install Java 26. I intend to keep using 25 until the next LTS.
Vs code devcontainer is actually very fast after the initial container build and everybody (we have two devs 😅) can use any OS for development.
I'm on fedora and my colleague uses Ubuntu and we had quite many issues getting everything installed correctly, thus devcontainer
Similar to https://clojurians.slack.com/archives/C0744GXCJ/p1768934305171669?
Is it my imagination, or did Clojure 1.12 or 1.11 add support for extending protocols to arrays? I know we used to do it via some hackery around extend .
yes, 1.12 with the array syntax: String/1
Ahhh, thanks! I was trying to figure out what to search for.
i thought it was in the clojure core tests, but i don't see it so i don't actually know if it's explicitly supported or not
yes, it's intentional: https://clojure.atlassian.net/browse/CLJ-1381
> This is solved as a by-product of https://clojure.atlassian.net/browse/CLJ-2807#icft=CLJ-2807 which now provides an array class syntax.
(extend-protocol P
byte/1 (p [_] "bytes")
int/1 (p [_] "ints"))
(p (byte-array 10)) ;; "bytes"
(p (int-array 10)) ;; "ints"
It is supported
When you’re developing a library or API that’s already in use, when it comes time to release a new major version, how do you go about creating a migration guide for users? We basically have two categories of changes: • In some places, the syntax/contract stays the same, so the upgrade is entirely under the hood and users don’t need to do anything. • In other places, the syntax or contract changes. That’s the challenging part: identifying all of the places where user code will need to change. Leaving deprecation notices aside, what’s the best practice for communicating those changes? Is it something like an exhaustive list of “all calls that looked like this should now look like that”? Or is there a more elegant way?
Maybe like this: https://weavejester.github.io/hiccup/hiccup.core.html
Thanks. Question - why don’t you link to the latest version on the deprecated page? It was easy enough to find it in the sidebar so maybe it’s not necessary, but just wondering. I’m thinking about how much guidance will be necessary for the developer. We plan to have something like a skill for agents to help the developer with migration, but we also want a human-readable (not just natural language) part to be both a technical reference and a guide.
In general, in the Clojure world we try very hard to not introduce breaking changes. If a library needs to introduce a breaking change, the recommendation is to use new function names or a whole new namespace, leaving the old functionality intact. Then it is up to users whether they migrate or not, and they can safely upgrade to your new version without any changes in their own code -- and then decide whether to migrate in the future, hopefully in a piecemeal fashion.
@matthew309 Re: your question -- hrtmt is not the author, he was just posting that as an example of how someone else indicated deprecation, and it is done in source code as metadata https://github.com/weavejester/hiccup/blob/2.0.0-RC1/src/hiccup/core.clj (so there's no control over linking to anything in the docs based on that).
@seancorfield Oh, thank you. I appreciate your thorough replies here.