-
Notifications
You must be signed in to change notification settings - Fork 250
macOS EOL'd system ruby makes running sprout difficult #99
Comments
It seems more problematic than just installing Ruby early. Because you need Homebrew to install Ruby (at least with ram), but need a Ruby > 2.0.0 to install Homebrew. |
The idea of an omnibus for Sprout has come up before. Perhaps this just
tipped the need for this.
Aram, is this what you mean about Sprout bringing its own Ruby?
…On Mon, 6 Feb 2017 at 3:57 pm, Davis W. Frank ***@***.***> wrote:
It seems more problematic than just installing Ruby early. Because you
need Homebrew to install Ruby (at least with ram), but need a Ruby > 2.0.0
to install Homebrew.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#99 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAfIrrHJMKdE1nsSVawsOb8mDanYx_-ks5rZqhNgaJpZM4LmHyB>
.
|
Here's what I did yesterday that worked, mostly:
This completed the sprout run without error. Most apps seem installed at least. And bash-it, etc., are present. However, Homebrew complains that the Casks are in I'm fine with this approach. I feel leaving Sprout is going to be a move backwards. |
Regarding #99 (comment) homebrew still/currently uses system ruby on macOS. Unfortunately this is ruby
If one is willing to double-bootstrap (first brew.sh, then sprout) then the recipe above works fine. This may be the way to go ultimately. If so then Regarding Casks in |
Abandoning sprout after so much investment feels backwards, especially since it still works fine on new Ruby + Chef versions. Additionally, After using many configuration & provisioning tools, I've seen that bootstrapping is one of the major problematic and difficult issues on any OS. This is especially true for Mac OSX due to the hard to automate dependencies such as XCode + xcode-command-line-tools, and the out of date system ruby. So really, our problem is bootstrapping. This is a solvable problem, as myself, @infews, and others have managed to get from a fresh OSX install to a working one with RVM + Chef 12.x + soloist. So that means a path from fresh -> provisioned with Just as with any configuration management & provisioning software, starting from scratch becomes important for testing to ensure missing dependencies are handled. Knowing this, I had originally intended to set up a So I still have yet to get a good Background: I've used |
Update: So it looks like the chef/bento project has templates now for |
@trinitronx Thanks for that. Have there been any conversations since then? Is Pivotal actively using this tool? I just unboxed our first proper pairing station here at Periscope Data and I'd love to get us on Sprout-Wrap. |
@ClayShentrup I made some changes to the Before adopting the |
Thanks @aramprice! I'll give it a spin soon. |
See #102 for changes |
Related Homebrew/homebrew-core#14418 |
Good news: macOS 10.13 beta 3 has a system Ruby of 2.3.3p222 |
As @wendorf points out, now that High Sierra's out we have:
|
@trinitronx @wendorf good news is that un-pinning gems allows sprout to work on High Sierra (macOS 10.13) but unfortunately Travis CI doesn't support 10.13 as noted here. |
@aramprice : Of course... d'oh! It looks like they have planned support for
Technically if sprout were using
But of course, that defeats the purpose of testing the bootstrapping process using pre-existing system ruby. |
Not sure if you guys have tested it yet, but it looks like Travis CI now supports macOS |
I've been converting some of the cookbooks to use this, notably https://github.com/pivotal-sprout/sprout-base, https://github.com/pivotal-sprout/sprout-chruby, and https://github.com/pivotal-sprout/sprout-git See https://github.com/search?q=org%3Apivotal-sprout+xcode9.3&type=Code Ex: https://github.com/pivotal-sprout/sprout-base/blob/master/.travis.yml#L3 |
Many of the I mention this hear since |
@aramprice: Thanks for pointing out the ones using the new Travis CI image! I'll have to look into adding some testing to my Sounds good about migrating to |
@trinitronx I may have spoken a tad too soon about the viability of the recipes noted above. I ported the changes I had from other repos to #103 and the travis run appears to have succeeded: I still think that nearly all of the recipes should be dropped in favor of a FWIW we seem to be moving away from sprout mostly because folks have limited familiarity with chef and building enough context to understand it drives most folks to use Personally I'm experimenting with dotfiles and a |
@aramprice It's interesting to hear about that experience with "indirection". Do you feel similarly about this project from Labs Seattle? (Based on Ansible apparently.) |
@ClayShentrup I haven't looked that closely at seattle-beach/alfalfa but I think there is a similar (slightly lower?) level of indirection. For sprout at least we decided at one point that it would be macOS only. At that point there was no need for the multi-OS capabilities of chef. It's not clear that Another lens to see this through: why should a developer invest in understanding a technology they wouldn't otherwise use (in this case chef) in order to automate something ( |
@aramprice I agree. In fact, the last two times I rebuilt a macOS machine from scratch I bypassed Sprout-wrap entirely because I was having too much trouble wrestling with the recipes. |
Hmm, interesting... hadn't realized Also, it's proven very useful to install DAW software + plugins and other things on my home laptop. I wonder if
|
Thanks for the success story (stories), it is great to hear about sprout automation paying off folks! The Based on the puzzled looks I get from folks when explaining chef cookbooks to folks though I suspect that it won't be enough to revitalize |
I just had to provision a new MacBook Pro (15-inch, 2019, This was starting out with system ruby too. I avoided installing I've made some fixes to my bootstrap script, and finally got a successful Chef run after removing or migrating deprecated homebrew casks, recipes, etc... The related changes are in |
I've gotten sprout + In case anyone's still interested in using I've moved my |
I can't speak for anyone else, but in my eyes you are the steward of sprout-wrap, and I like the idea of a proper hard fork & rename to avoid the accidental PR. |
macOS (v10.12) ships with an EOL'd version of ruby (v2.0.0p648),
This is problematic for running sprout because many ruby gems are dropping support for this version of ruby. The following version locks are currently required to run sprout: https://github.com/pivotal-sprout/sprout-chruby/blob/master/Gemfile#L12-L20
There are a number of possible options for addressing the lagging ruby support in macOS.
One Idea is to replace the sprout ecosystem with something based on Brewfile plus some sort of dotfiles tooling. This would be losing the investment in cookbooks that have been created.
Another idea would be for sprout to bring its own ruby. This would increase boot-strap time but give a consistent ruby env which sprout and its associated gems could depend on.
I'm opening this issue as a place to further this discussion. Paging @wendorf, @cunnie, @hiremaga, ... Please tag anyone who might be interested.
The text was updated successfully, but these errors were encountered: