This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (39)
- # architecture (7)
- # aws (9)
- # babashka (111)
- # beginners (139)
- # bristol-clojurians (1)
- # calva (47)
- # chlorine-clover (5)
- # cider (17)
- # clj-kondo (26)
- # clojars (25)
- # clojure (251)
- # clojure-berlin (1)
- # clojure-dev (5)
- # clojure-europe (22)
- # clojure-france (1)
- # clojure-hungary (6)
- # clojure-losangeles (8)
- # clojure-nl (18)
- # clojure-spec (3)
- # clojure-uk (68)
- # clojured (32)
- # clojurescript (32)
- # core-async (10)
- # core-typed (120)
- # cursive (8)
- # datascript (10)
- # datomic (11)
- # docker (2)
- # emacs (6)
- # figwheel-main (4)
- # fulcro (10)
- # graalvm (92)
- # hoplon (2)
- # instaparse (9)
- # jobs (3)
- # jobs-discuss (31)
- # joker (2)
- # kaocha (1)
- # lambdaisland (5)
- # leiningen (10)
- # luminus (1)
- # lumo (14)
- # meander (30)
- # mid-cities-meetup (1)
- # midje (1)
- # off-topic (46)
- # pathom (22)
- # perun (2)
- # re-frame (10)
- # reitit (1)
- # remote-jobs (8)
- # shadow-cljs (71)
- # spacemacs (7)
- # sql (40)
- # tools-deps (31)
- # tree-sitter (11)
- # vim (14)
- # vscode (2)
- # xtdb (5)
there was a change (https://github.com/Homebrew/homebrew-core/commit/715900bfab494ccee4cadeea902d80ccce6e7a16) made in the homebrew clojure formula to install the latest adoptopenjdk, rather than just checking for an existing Java 8+. This was made by someone outside the Clojure community that just goes around changing things to use adoptopenjdk. This change is wrong, imo. I have filed an issue at https://github.com/Homebrew/homebrew-core/issues/50536 - if you have had surprising experiences, a comment on the issue would be helpful.
Do you think it makes sense for the Clojure community to take over the package in a tap?
well I have been contemplating making our own tap for a while. this may have just tipped the scale.
heh the homebrew version of maven also has this as a dependency now, oddly that's what bit me
> that just goes around changing things to use adoptopenjdk.
There's the more charitable interpretation that the Homebrew maintainers want to keep/enforce a consistent implementation and policy.
Two members of the Homebrew team suggest
JAVA_HOME, which doesn't sound too bad. Most importantly, that technical alternative doesn't appear addressed in the 2 threads
tbh setting up
JAVA_HOME sounds like bit of a pita - one would always want a smooth automagical installation instead, particulaly for beginners.
But it's reasonable to see why that not may be attainable in a huge project that specifically has the policy of disregarding LTS versions: https://github.com/Homebrew/homebrew-core/commit/715900bfab494ccee4cadeea902d80ccce6e7a16#r37415334
To test, I just updated clojure on my Mac using brew, and it did install openjdk13 via Brew, which had not been installed on my system before. I have several 2-line bash scripts on my system that simply set the JAVA_HOME env variable to a different JDK install on my system, and also add the binary directory to my PATH, then ran
clojure , and it used the one in JAVA_HOME, not openjdk13. So it is working as they advertise.
Whether or not someone wants http://clojure.org install instructions to mention things like this when installing view Homebrew, I do not know.
Noobie CS-Student here. Roast me if I am wrong but shouldn’t a package manger provide you the recommended way to install software? The argument “You need Java to use Clojure, we install that dependency.” by SMillerDev sounds a bit off to me. Maybe they don’t see the impact of such decision. To treat Clojure and its dependencies like every other piece of software … seems to be a very “naive” thought. The most programs aren’t also environments like Clojure.
The same argument could be made for other developer tools/environments that require Java, like Maven, and they did it for Maven, too. Rule one of open source: every open source project has decision makers, and they make the decisions. Others might not like them, but the project decision makers are entirely within their rights to make them. In response, others can complain, argue, provide evidence, open issues, etc. In the end, the decision makers of a project decide.
Anyone can also choose to create their own fork of the open source project, under the appropriate license, and do the work themselves. For some things, that is worth the effort. For most, it often is not -- it just takes too much time to maintain a fork in many cases.
I totally agree with you. I just thought the hole thing about brew formulas was to be transparent and as flexible as possible. So that the maintainer/decision maker of a formula has the right set of tools to communicate and deploy his software.
And the decision makers get to decide what high level statements like "the maintainer/decision maker of a formula has the right set of tools to communicate and deploy his software." means, if that is even what the Homebrew project claims to provide.
I also ran into this with maven this weekend. I was already using asdf-vm (https://asdf-vm.com/) for managing nodejs, java, python, etc, so I just installed maven through asdf instead of brew. I guess I’ll also install Clojure using asdf in the future.
@U064X3EF3 I’m working on updating the Clojure plugin for the
asdf version manager. Where do I go to find the enumerated list of all point releases of Clojure e.g. 220.127.116.119 vs. 18.104.22.1680 vs 22.214.171.1240_1? This URL doesn’t have the point releases: https://repo1.maven.org/maven2/org/clojure/clojure/1.10.1/ (found via https://clojure.org/community/downloads)
@UGNFXV1FA I’m also a very happy
asdf user. The “blessed” Clojure plugin for asdf https://github.com/halcyon/asdf-clojure hasn’t been kept up-to-date with minor releases. I have a forked copy of the
versions file @ https://github.com/adamfeldman/asdf-clojure/blob/master/bin/versions
The full version only applies to the Clojure tools, which is not on maven anywhere
The https://github.com/clojure/brew-install/blob/1.10.1/CHANGELOG.md is a human source of that info or git tags on that repo
And soon https://github.com/clojure/homebrew-tools will be an alternate source of info
That’s awesome, looking forward to adopting your new Homebrew tap.
I don’t feel a strong need to use
asdf to manage my Clojure versions, because I don’t often find myself switching between Clojure versions (typically just update my system to the latest).
For those interested in protobuf/clj interfacing, just pushed the first alpha version: https://github.com/hkupty/defteron
I was thinking on a macro-based alternative for known classes, but it's not the focus for my usecase...
Confluent is busy adding support for protobuf to schema registry (it's in current master) so might be interesting for #apache-kafka #jackdaw
This is incredible. The need to precompile protobuf has always been a problem for me.
Hum, maybe we're talking about different things. This is runtime reflection on top of protobuf java objects. Is this still what you're looking for?
I've always thought the compilation step and external cli is just a hindrance to the repl with it. And setup for new people joining a project.
Well, currently it only deals with java->clj conversion of protobuf, but @U09LZR36F gave me a brilliant idea and I'll investigate further. Feel free to fork, test, open issues or PRs. :)