Fork me on GitHub
#announcements
<
2020-02-21
>
Alex Miller (Clojure team)15:02:55

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.

Alex Miller (Clojure team)15:02:21

...and they just closed the issue

🤯 12
hindol15:02:03

Do you think it makes sense for the Clojure community to take over the package in a tap?

Michael J Dorian15:02:34

That seems... remarkably hostile of them.

28
Alex Miller (Clojure team)15:02:00

well I have been contemplating making our own tap for a while. this may have just tipped the scale.

💯 12
Alex Miller (Clojure team)15:02:00

it is really a pain though to have both

lilactown16:02:20

Yeah ideally we would pull it from th main repo

👍 4
gerred16:02:15

heh the homebrew version of maven also has this as a dependency now, oddly that's what bit me

vemv16:02:00

> 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

andy.fingerhut18:02:31

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.

andy.fingerhut18:02:04

Whether or not someone wants http://clojure.org install instructions to mention things like this when installing view Homebrew, I do not know.

Space-Otter21:02:56

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.

andy.fingerhut22:02:06

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.

andy.fingerhut22:02:51

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.

Space-Otter00:02:50

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.

andy.fingerhut01:02:17

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.

Stefan09:02:25

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.

adamfeldman17:02:25

@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. 1.10.1.469 vs. 1.10.1.510 vs 1.10.1.510_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

👍 4
Alex Miller (Clojure team)17:02:33

The full version only applies to the Clojure tools, which is not on maven anywhere

Alex Miller (Clojure team)17:02:54

Working on that now

👍 4
adamfeldman17:02:50

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

hkupty16:02:22

For those interested in protobuf/clj interfacing, just pushed the first alpha version: https://github.com/hkupty/defteron

😮 16
👍 12
❤️ 8
parrot 8
dominicm17:02:43

Is this runtime?!

hkupty17:02:10

I was thinking on a macro-based alternative for known classes, but it's not the focus for my usecase...

gklijs17:02:10

Confluent is busy adding support for protobuf to schema registry (it's in current master) so might be interesting for #apache-kafka #jackdaw

👍 8
😎 8
dominicm17:02:46

This is incredible. The need to precompile protobuf has always been a problem for me.

dominicm17:02:48

I assume it can work on the binary form?

hkupty17:02:28

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?

dominicm17:02:32

Oh. I thought it was protobuf serialization.

dominicm17:02:53

And deserialization.

hkupty17:02:03

That's not a bad idea to be honest

hkupty17:02:12

I'll look into that

dominicm17:02:12

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.

hindol17:02:51

What kind of help wanted? This project is interesting to me.

hkupty18:02:36

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

jaide18:02:31

Nice! About 2 years ago I wrote a small CLI to query NYC realtime subway data. I struggled my way through the protobuf support but eventually got it working. I bet this tool could help a lot!