Formula in homebrew/core for my app uses slow non-native version

[weavejester]

I maintain cljfmt, a formatter for Clojure code, and I've noticed someone's added it to Homebrew core as a formula.

Unfortunately it installs the JVM bytecode version rather than the natively compiled version, so Homebrew's version of cljfmt has a significantly slower startup than the recommended version (~1700ms vs. 1ms).

I'm unsure what to do in this case, and I'd appreciate some advice on how to proceed.

I could see about submitting a change to the formula that downloads the precompiled binaries instead, but I'm unsure whether or not a brew formula is required to compile from scratch. I could also submit a version that uses GraalVM to compile the binaries, but this would create quite a bit of overhead, unless bottles are meant to cache the binaries produced in this case. Or the formula could be deprecated, and a custom tap used instead.

What would be the best option?

[p-linnane]

Everything in Homebrew/core must be built from source on our CI. Feel free to open a PR modifying the formula if you can improve it.

[weavejester]

What if it can't be improved while adhering to the guidelines?

In this case the optimized version is compiled with GraalVM native-image, but as this doesn't have a brew formula I can't add it as a formula dependency. I guess I could download the GraalVM binary, put it in a temporary directory, and then use that to compile cljfmt. Would that be permitted, and if so could bottles be used to cache the output binaries so normal users can avoid downloading GraalVM?

Alternatively, I could put in a request to deprecate the cljfmt in homebrew/core in favor of a binary version from a tap, but perhaps that should be a last resort. Do you think it's possible to write an acceptable formula that compiles JVM class files with GraalVM native-image, or should I put in a PR to deprecate the cljfmt formula?

[p-linnane]

From your explanation, it sounds like the current state of the formula is the best we can do. We do not remove software from Homebrew/core in favor of other taps. If you plan to maintain your own tap, you'll just need to instruct your users on how to install from that tap.

[SMillerDev]

You could also make a pull request to make a GraalVM formula, and subsequently use that to compile the software

[weavejester]

I've taken a cursory look over GraalVM, but it doesn't have any immediately obvious instructions on how to build from source. I'll take a further look, but I suspect someone with more expertise will be required.

It also looks like this issue is common to a number of other JVM command-line tools that rely on GraalVM compilation; that is, the homebrew core version of the tool uses a jar, while the recommended version of the tool uses a natively compiled executable.

If deprecation isn't the solution, then is there another way of indicating that a particular formula is not recommended to be used? Is it worth adding a warning to the affected formulae?

[p-linnane]

You can add a note to your README pointing users to your tap if you prefer.

[weavejester]

Oh, I definitely plan to do that. My concern is that someone might use the homebrew core version without checking the project README. I know that I've personally installed plenty of things via homebrew without checking the project homepage first!

Is it therefore worth adding a warning to the formula? So that when a user installs it they're informed that this is a less performant version and then points them toward the project homepage.