From @derekprior: > I never used NVM. I just kept my homebrew installed version pinned to > the version we were using. As a company this is probably totally fine > because we don't jump back and forth between node projects like we do > with Ruby projects. Also, there is no "system" node to worry about. #341 (comment)
We previously relied on the version of Git that comes with Xcode. The Homebrew version is easier to upgrade when new versions of Git are released, such as yesterday's security patch: https://github.com/blog/1938-git-client-vulnerability-announced
I saw this problem while installing Ruby 2.1.4. Installing libyaml first solved the problem. https://github.com/sstephenson/ruby-build/wiki#suggested-build-environment
I haven't been using `heroku config:pull`, etc. for some time. Instead, I've been using more targeted shell lines insides our [`bin/setup`] convention, such as: if ! grep -F "FILEPICKER" .env > /dev/null; then heroku config --remote staging | grep "FILEPICKER" >> .env sed -i '' 's/\:/=/' .env sed -i '' 's/ //g' .env fi [`bin/setup`]: http://robots.thoughtbot.com/bin-setup This is more targeted and automated than using `heroku config:pull`.
* Don't repeat ourselves by using variables. * Use more consistent variable naming and use of `local` in functions. * Use `snake_case` for variable names and `ALLCAPS` for environment variables. https://github.com/thoughtbot/guides/tree/master/style#shell * Use Bash double-bracket. * Set current shell to newest Ruby version. * Don't install `--pre` version of Bundler. https://www.ruby-lang.org/en/news/2014/10/27/ruby-2-1-4-released/
Upstream maintainers put thought into what is and what isn't sensible to include by default. Those decisions establish a de facto standard that is broader in scope than Laptop: Homebrew users, library users, etc. The further we stray from the defaults, the more likely we are to run into problems, and those problems will be harder. The most widely experienced, most urgent, and most rapidly fixed problems will be problems with installing using formula defaults. Problems from using non-defaults are relatively lonely. Also, Homebrew bottles are awesome: https://github.com/Homebrew/homebrew/wiki/FAQ#why-do-you-compile-everything Using options forces an install from source rather than a bottle, which is much, much slower: > Options were passed to the install command i.e. `brew install > $FORMULA` will use a bottled version of `$FORMULA`, but `brew install > $FORMULA --enable-bar` will trigger a source build.
* Use the same Git/GitHub approach for Mac as we do for Linux. * This makes upgrading easier via `git pull`. * Add idempotency `if` guards. * Use bash-preferred bracket-bracket style. http://robots.thoughtbot.com/the-unix-shells-humble-if
`&>` redirects both `stderr` and `stdout`. `>` redirects only stdout. Use `&>` when we explicitly want to ignore/discard error messages, which is rarely. `command -v` outputs only stdout. So, `>` is appropriate because there is expected `stderr` output. In the rare case that command fails, we want the reason printed.
Use preferred POSIX `command -v` test for command existence instead of previous `which` technique. `which` exits with status `1` if nothing is found. That would cause the script to abort because we use `set -e`. http://stackoverflow.com/questions/592620/how-to-check-if-a-program-exists-from-a-bash-script Remove GCC dependency in mac script GCC is no longer necessary to compile Ruby. It was fixed in Ruby about two years ago. LLVM has been supported since 1.9.3-p125. https://bugs.ruby-lang.org/issues/5076 http://stackoverflow.com/questions/8032824/cant-install-ruby-under-lion-with-rvm-gcc-issues
* Use http://ruby.thoughtbot.com/latest endpoint. * We'll update the file when necessary, which is stored on S3 and served via Fastly. * Apply style guideline: "Use snake_case for variable names and ALLCAPS for environment variables." https://github.com/thoughtbot/guides/tree/master/style#shell
The previous method places the `hub` command in ~/bin/hub, which shows up in the dotfiles repo for thoughtbot/dotfiles users. We could gitignore the `bin/hub` gem there, but the hub README recommends using Homebrew or a package manager when it is available. This leaves the Linux version functionally the same.
* Set it globally for OS X. * Determine number of cores dynamically. * Pick one number less than number of cores to avoid deadlock errors. http://archlever.blogspot.com/2013/09/lies-damned-lies-and-truths-backed-by.html * Only install `--pre` for Bundler. * Remove `pg` and `unicorn` gems as they will be installed during `bundle` for a Rails project.