Every time a new Crystal release comes out it inevitably gets delayed for macOS because it has to wait for approval from the home-brew core team. I think this is totally reasonable for them to do, but it does make it hard for the Crystal community because some libs work for newer versions but can’t be easily used on Mac.
My suggestion is to have a crystal home-brew tap so the core team can release whenever they need. This is what we do for Lucky https://github.com/luckyframework/homebrew-lucky and https://github.com/paulcsmith/up. It is only one extra step
brew tap luckyframework/homebrew-lucky and then works just like normal.
Yes, we had a tap but eventually we moved to the official homebrew, I think because it’s more accesible. Now I don’t know anymore, I think we should have a tap and get us out of the official repository.
The official brew formula is the main way to distribute crystal in osx I would say. A tap can be used but will never be as straight as having the formula there.
As a workaround, on mac, using the hosted .pkg or .tar.gz for darwing in github is really simple. Maybe we should advertise that as an alternative.
The main thing to solve, that is taken care in https://github.com/crystal-lang/crystal/pull/7705 , is that the release + CI update process needs to not depend on artifacts we don’t have control of.
I’m not 100% sure I understand. Adding a tap is just one line to run and then never needs to be run again. The advantage is Crystal can 100% control the release date. So far I don’t think home-brew has ever had new versions of Crystal at the same time as other platforms (or even the same day as the blog post) and that makes it much harder for libraries to get things working since some people can get the latest release and others can’t (without going through a bunch of hoops). It’s also very confusing for new users who expect to be on the new version that was just announced but are actually on an older one.
I don’t want to be too pushy here at all so if those problems are smaller than having users add a tap then that is ok. I just hope to understand a bit more why sticking with the official home-brew is worth it while Crystal has breaking changes every few months. It seems like when Crystal is more stable (1.0?) being in the official home-brew tap would be worth it
One more thought, even though it is in the official Home-brew tap, most people still have to look up how to install Crystal anyway. Everyone I’ve worked with tries
brew install crystal (not
brew install crystal-lang) so I would argue that also adding the step of adding the tap is not a big deal. From my experience with other projects asking to add a tap has never been an issue
Anyway, just my 2 cents!
Also, we don’t provide Crystal in any other official medium, for example Ubuntu. You have to add our repository and download crystal from there. For homebrew a tap would be equivalent. I think homebrew is the only official thing and I’d personally get rid of it. Maybe once we reach 1.0 it’ll make more sense.
I realize my request may seem odd without an example.
Nearly every time a new version of Crystal comes out something breaks in Lucky or one of its libraries (this is ok! Crystal is changing :D)
The problem that comes up is that I can’t reliably release a working version of Lucky.
If I release one that works on the new version of Crystal, macOS users that install Crystal will not be able to use it. If I keep the version of Lucky that works on the old version of Crystal while I wait for home-brew then Linux users will have the latest version of Crystal and Lucky won’t work. Either way someone has a broken version of Lucky until the new version of Crystal is readily available.
This happens every time and adds a great deal of stress/support issues. Anyway, maybe that explains why I think this is important not just for library authors but also those that are new to Crystal and can’t get things to work.
The request is not odd @paulcsmith.
I think that homebrew is the main distribution for crystal in osx. Before we used to have the tap, but once we got the
crystal-lang ;-) ) names there we migrate to support that.
These release raise some flags on their side and that is the reason of the current delays.
Having our own tap would mean to either:
- Post the PR as a tap forcing users to bulid the compiler in release mode. Leading for slow installation for end users.
- Write a tap that will essentially download the tar.gz from github with no build option. Leading to different codebase of formulas to maintain and different artifacts layout raising questions not only of how Crystal was installed (homebrew) but with which formula/tap.
I think both have serious impact and I think is better to have either official formula or GitHub downloads directly.
I’m happy to change my mind and forgot/solve the issues that make me reluctant to have a tap, as long as someone offers a solution/different perspective/refute my worries.
Or use the package manager agnostic https://github.com/pine/crenv
I think that’s at most like 5 minutes. I don’t think it’s a big issue. Plus this will definitely run on a Mac so we can be sure it will run successfully (the memory limit won’t be hit, etc.)
crenv often because shards are at different crystal versions. it works well for versions that have not hit homebrew yet.
Maybe a tap for “head” or…latest? I’d imagine the “standard way” would be from the central brew repo…