* Snow Leopard was released in August, 2009 (about five years ago). * Yosemite will be released in a couple of months. * We support the last three versions of Ubuntu, so this is a little more consistent. * Use the same format as the Linux "Requirements" section for consistency.
Fixes thoughtbot#260 This is a soft error that occurs when Laptop is run and PostgreSQL isn't currently loaded by `launchclt`, e.g. on the first run of Laptop: Starting Postgres ... /Users/wellmade/Library/LaunchAgents/homebrew.mxcl.postgresql.plist -> /usr/local/opt/postgresql/homebrew.mxcl.postgresql.plist launchctl: Error unloading: homebrew.mxcl.postgresql The fix would probably be to check `launchctl list` to see if the service is already loaded before calling `launchctl unload`. This small added complexity probably justifies a function for running appropriate `launchctl` commands. Homebrew has a strong convention for the naming of `launchd` plists: "homebrew.mxcl.FORMULA_NAME.plist", e.g. "homebrew.mxcl.postgresql.plist" and "homebrew.mxcl.redis.plist". This likely makes a function to do the `launchctl` work fairly straightforward.
Fixes thoughtbot#259 Laptop raises the following warning on `brew link openssl ` when OpenSSL has already been linked: Warning: Already linked: /usr/local/Cellar/openssl/1.0.1h To relink: brew unlink openssl && brew link openssl I think the resolution is straightforward: follow Homebrew's recommendation and `brew unlink` before `brew link`. I verified that `brew unlink` exits with success even if the formula wasn't previously linked as would be the case the first time Laptop is installed.
Fixes thoughtbot#258 The following doesn't behave as intended: brew_install_or_upgrade 'postgres' because "postgres" is an alias, not the full name of the formula. The actual formula name is "postgresql". The first time `brew_install_or_upgrade 'postgres'` is invoked it works as expected — `brew install postgres` is run. Additional invocations result in `brew install` instead of the expected `brew upgrade`. The `brew_install_or_upgrade` function uses `brew list -1` to obtain a complete list of installed packages, and these package names will be the actual package names. So, grepping for an alias (with the `-x` option) won't match: $ brew list -1 | grep -Fx postgres Note that there's no output, even though PostgreSQL is installed. Using the full package name behaves as expected: $ brew list -1 | grep -Fx postgresql postgresql Rather than passing on the first argument to `brew_install_or_upgrade` to the `brew list` commands, the argument should first be expanded to the actual package name.
Fixes thoughtbot#257 On a clean OS X Mavericks, Laptop outputs an error message towards the end of the install script when `brew_install_or_upgrade` is invoked for OpenSSL: Upgrading and linking OpenSSL ... Error: openssl-1.0.1h already installed Linking /usr/local/Cellar/openssl/1.0.1h... 1139 symlinks created The current version of OpenSSL was installed earlier as a dependency of PostgreSQL. In general, a similar error will be logged whenever `brew_install_or_upgrade` is called for an installed package that's already up to date. Currently, Laptop discards the error exit code of `brew upgrade` as follows: (brew upgrade "$@") || true In addition to logging an error when there isn't truly an error, this approach can cause real `brew upgrade` errors and potential bugs in Laptop to be masked (e.g. Homebrew formula build failures or Laptop mistakenly invoking `brew upgrade` for a package that isn't actually installed). I think a better approach would be to check whether the installed package is the same version as the current Homebrew formula before attempting `brew upgrade`.
Homebrew's install script checks whether the command line tools are installed, and, only if necessary, will run `xcode-select --install`. https://github.com/Homebrew/homebrew/blob/go/install#L162 The test they are using depends in part on a heuristic: Homebrew/homebrew@afa4549 I confirmed that it works on a clean 10.9 install. We also should not instruct the user to run `sudo xcodebuild -license` at all. Here's why: The `xcodebuild program` isn't included in OS X Mavericks. When you run `xcodebuild`, you're actually finding one of 83 shims found in `/usr/bin` that are included in Mavericks. These shims are an important part of how the `xcode-select` mechanism works. When the command line developer tools have not been installed, invoking any of these shims won't do anything other than prompt you to install the command line developer tools: $ xcodebuild -license xcode-select: note: no developer tools were found at '/Applications/Xcode.app', requesting install. Choose an option in the dialog to download the command line developer tools. (And, the GUI install dialog is presented.) Of course, since the real `xcodebuild` program isn't actually available, it doesn't make sense to try and use it to accept the Xcode License Agreement. Instead, go straight to installing with `xcode-select --install` (xcode-select comes with OS X Mavericks and is not a shim): $ xcode-select --install xcode-select: note: install requested for command line developer tools And, the exact same GUI install dialog is presented (prompting the user to either "Get Xcode" from the App Store or immediately "Install" the command line developer tools). For more about `xcode-select` and it's shims, see `man xcode-select`. This also removes redundant Vagrant setup instructions and capitalize Vagrant.
This uses installer(1). On GNU we already install `heroku-toolbelt` using apt, and that package has a dependency on the `foreman` package. We install this via installer(1) instead of gem(1) so that it remains regardless of the development Ruby setup. We install this via installer(1) instead of from the `Gemfile` so that it remains regardless of what other developers do on the project (as described by David Dollar).
Includes: * Fix the "brew_install_or_upgrade" function, use it for all components * Remove executable perms * Skip installing an already installed ruby Technically re-running laptop is not idempotent in that it will upgrade brew-installed items and potentially install a new ruby. I feel this is expected and wanted.
Includes: * A minimal gem, rake, and rspec environment * The Distro class wraps up commands to test and provision vagrant boxes * Publishing boxes to s3 has been simplified and improved * Significant documentation updates New laptop specs should now be significantly easier to write and understand.
If postgresql was installed and started in a previous run, start causes: Error: Service `postgresql` already started, use `brew services restart postgresql` When developing changes to these scripts, it's important to be able to run and rerun this script without removing applications.
Vagrant boxes can be created automatically after a successful run of the laptop test suite. These vagrant boxes are published to [vagrantcloud](http://vagrantcloud.com/thoughtbot/) and should be a solid start on a vagrant dev box suitable for modern ruby and ruby-on-rails development. Improvements include: * Vagrantfiles fixed to have predictable names * test/runner.sh now knows how to render vagrant boxes after tests are successful * Error reporting improvements * Full documentation on creating new base boxes We now require vagrant >= 1.5.0 to use the automated test suite built into laptop.