https://github.com/taylorlapeyre/.files/blob/master/osx/boot...
A shell script will be something like
install this package
create this file
change this line in a configuration file
make sure this package is installed
make sure this file exists
make sure this line is like this in this config file
Ansible on the other hand only performs the tasks in the playbook that need to be performed: if the condition is already satisfied, there's nothing to do.
This is especially convenient if your script fails at some point: you can fix the directive and replay the playbook, and it will restart from where it left off. With shell scripts you have to do it manually (comment out the first part?), which is error-prone and time-consuming.
I will, however, offer that a well-designed shell script should be able to be run many times in a row without causing any problems. The above script is an example of this.
If I wanted to change something in my configuration script, that's totally fine! In fact, I do change it all the time. Since all it does is ask you whether you want homebrew to install something, there is very little risk (if any) of something "going wrong."
We use ansible for configuring servers. Using this to configure our machines would be cake.
- Read up on the documentation for osxc or battle school
- Look at other configuration files to get a feel for what mine needs to look like.
- Learn about the differences between playbooks or recepies or what have you.
- Download some proprietary software that I will likely never use again.
This is all mental overhead to me.
In comparison, how do you create your own bash script? You already know how to do most of it. If not, just look at the script above. It doesn't require a genius to understand a simple bash function. This approach will take you at most, 5 minutes.
Or maybe I'm just not seeing some huge advantage of these large boxen-esque frameworks for installing some programs.
A couple of weeks ago I decided to backup my hard drive, reformat it and reinstall OS X Mavericks to get rid of the cruft that seems to have built up in 4 years, updating from every OS since Mac OS X 10.5 Leopard.
I made halfhearted attempts to organize my dotfiles and configuration in the past, like the cool kids do on Github. That’s when I learned about Homebrew Cask (http://caskroom.io) which makes it super easy to install the GUI apps I install on whatever Mac I’m using—iTerm, Transmission, Vagrant, Virtual Box, etc.
And now I have them in a Brewfile (http://robots.thoughtbot.com/brewfile-a-gemfile-but-for-home...) under version control in case I need to install the whole shebang on another Mac.
And now brew update && brew upgrade updates everything.
What is preventing `brew cask install firefox` from installing something malicious? When I download an application manually, I trust the site I'm on by virtue of being there and being savvy enough to know it's a legitimate site. But when you script it, you lose the ability to gauge see for yourself what you're downloading.
I realize I could probably do: `brew cask info firefox`, find the ruby file it points to (https://github.com/caskroom/homebrew-cask/commits/master/Cas...), open that up, verify the link is trustworthy.. but I don't want to do that for every installation. And if it's valid now, what's to prevent it from changing in the future?
How do you guys justify using cask?
I'm going to address a few of your points specifically.
> There are no upgrades, in many cases it doesn't work.
It's true that `brew cask upgrade` is not yet a thing. I would very much like it to be. I've been sort of avoiding work on the feature for fear of messing it up. But that's no reason to not try to make something work! :) Maybe I'll use this as an occasion to start digging in and getting my hands dirty.
> At the end of the day, it duplicates some of the Homebrew functionality - some non-GUI packages are getting into Cask, because possibly Homebrew doesn't want them - it's a bit confusing as well.
If the purpose of the project is not clear, that's definitely a problem. I'm not aware of many (any?) purely non-gui apps making it in to Cask. The `Homebrew/homebrew-binary` tap is the place for those. I'll go review our included Casks to make sure things are clear.
> I think efforts should be put into merging into Homebrew instead of keeping it separate.
I can understand this opinion, but I think we may actually end up going in the other direction. The places we share code with Homebrew have been the biggest problem areas for us. We are already 90% code independent from Homebrew, and I think moving Cask to its own world may benefit both the project and the users. But of course that's a conversation to have with the (amazing!) project team.
I’ve been using ~/Applications forever for beta testing and accessing two different versions of the same app.
export HOMEBREW_CASK_OPTS="--appdir=/Applications"Edit: Wow with the downvotes. I'm just offering feedback in a polite manner for what a lot of others are probably thinking.
Note that you shouldn't be confident using it too, it's still a very early project and, at the beginning, it was only meant to be used by me ... But I intend to make it much better !
https://github.com/32degrees/battleschool
If you're going to do this on a wider scale (multiple machines, managed in an organization), the best tools right now are AutoPKG and Munki:
https://github.com/autopkg/autopkg http://code.google.com/p/munki/
Although they are both configuration management tools, they are different.
What kind of issues did you have with chef? And when?
It's probably just me, but it seems like all of these require too much investment time before you have something usable for future use (replicating your current environment).
Which brings me to this, how about a script that analyzes what you already have installed and creates this set up for you which you can customize to easily add/remove packages/apps/installers using Boxen and similar? Anyone know of such tools? My MBP is full of crud after using SuperDuper!/Time Machine for several years to start new macbook setups and installing new versions of OS X on top of the old OS.