Closes#563Closes#587Closes#600
This makes the following changes:
* Installs asdf via Homebrew, thanks @jdbann in #592 and @gssbzn in #597
* The latest version of the asdf nodejs plugin takes care of the keyring stuff itself.
Closes#589
This adds support for properly installing Homebrew on either Apple Silicon or Intel machines to the correct Homebrew location on macOS.
Also changes to:
* Using `HEAD` instead of `master`, which comes from the Homebrew home page.
* Use the new `shellenv` recommended by Homebrew post-install next steps.
People used to have to tap Homebrew cask to use the `cask` command.
Homebrew have now integrated `cask` into the primary package manager.
`mac` was raising an error because the tap repository no longer exists.
We have dropped the tapping of `"homebrew/cask-cask"` from `mac`.
This may resolve some issues updating the languages, especially nodejs
where the asdf plugin maintains the signing keys required to verify the
package.
In order not to break anyone's laptop.local scripts, keep an alias of
`install_asdf_plugin` to the new method.
Qt, a dependency on capybara-webkit, causes a lot of install problems
and most recently more so. We're not using capybara-webkit so much now,
so we don't absolutely need Qt.
Fixes#499.
Fixes#533 and may make #515 unnecessary.
When installing Ruby and Node, we use `asdf list-all` to find the
latest version. For Ruby, the list includes previews and release
candidates as well as non-MRI versions. The script failed for me because
it tried to install version `ree-1.8.7-2012.02`. Filtering out
versions with letters should ensure we only install fully released MRI
versions.
At first, we did Ruby work, so we needed a ruby version manager.
Then we needed Node, so some of us added a node version manager.
Some of work with varying versions of Python, Elixir, Elm, etc.
ASDF lets us stop searching out solutions to the same problem in
each of these languges by supporting [plugins][1].
[1]: https://github.com/asdf-vm/asdf-plugins/tree/master/plugins
Add a force since there's sometimes a broken Homebrew update.
See https://github.com/Homebrew/brew/issues/1151
`brew update --force` will prevent stalling in the script.
Until the issue above is resolved,
it could pop up for someone trapped in a
'please update'-'already updated' loop.
While trying to run laptop on a new machine, I got the following error:
> A full installation of Xcode.app is required to compile this software.
> Installing just the Command Line Tools is not sufficient.
To truly fix this, we'd need to script the installation of Xcode, which
is beyond my skills at the moment. For now, I use a conditional in the
generated `Brewfile` to skip if Xcode is not installed.
* Move off Travis to Circle.
* Run the entire script on macOS infrastructure.
* Performance optimization:
Enforce a Ruby version to skip Ruby install
We're cheating slightly with this implementation,
but seems worth it for speed of build tradeoff:
* Use pre-installed XCode for compilers, etc.
* Use pre-installed Ruby version.
Related:
https://github.com/thoughtbot/laptop/issues/494
Universal ctags is a maintained and improved fork of
exuberant ctags. It adds many things, including better
ruby ctag support, and new supported languages.
https://github.com/universal-ctags/ctags
For users running the Laptop script
who once had `heroku-toolbelt` installed,
it's possible their `PATH` may be out of date.
Use a similar pattern for updating the link to the `heroku` binary
as we used when migrating `qmake` for `qt5.5` from `qt`.
Also, update documentation.
Related: 3b7845b849
* We install zsh via Homebrew in the Laptop script.
* Checking for a different path via `which zsh`
caused the user to have to type their password every script run
to allow for `chsh` to run.
From the chsh documentation:
When altering a login shell, and not the super-user, the user
may not change from a non-standard shell or to a non-standard shell.
Non-standard is defined as a shell not found in /etc/shells.
This reverts commit ef7408d6a1.
* `brew cleanup` removes Postgres.
* Migrating data in Postgres from old to new versions relies on
the previous version of Postgres to run `pg_upgrade`.
* Laptop shouldn't lose users' Postgres data.
* Those who don't mind starting their new Postgres databases
from scratch can `brew cleanup` in `~/.laptop.local`.
Sections:
* "Installing Homebrew packages ..."
* "Restarting services ..."
* "Relinking OpenSSL ..."
* "Configuring Ruby ..."
* "Running your customizations from ~/.laptop.local ..."
* "Cleaning up old Homebrew formulas ..."
Related:
* To make that work in the desired way,
print less noise in the custom functions.
* We don't need parity as customization in README.
* Match documentation to sections, move OpenSSL to Unix section.
* Move libyaml to after OpenSSL, before Ruby.
For example:
```
brew info brew-cask 2>/dev/null | head -1 | awk '{gsub(/:/, ""); print $1}'
caskroom/cask/brew-cask
brew info brew-cask 2>/dev/null | head -1 | awk '{gsub(/.*\//, ""); gsub(/:/, ""); print $1}'
brew-cask
```
`brew list -1` only has the shorter name listed
so it will try to re-install packages that are already installed.
* The Parity Homebrew [package] installs Heroku Toolbelt, Git, Postgres
but it seems nice for documentation purposes to
keep the Homebrew packages installed for the other dependencies.
* Tap the Homebrew formula first, so it updates with `brew update`.
[package]: https://github.com/thoughtbot/homebrew-formulae/blob/master/Formula/parity.rb
> Homebrew-Cask will now be kept up to date together with Homebrew
> If you haven’t yet,
> run `brew uninstall --force brew-cask; brew update`
> to switch to the new system.
e83c0099aa
> To start using Homebrew-Cask, you just need Homebrew installed.
0d290b15e8
Thomas Riboulet
Chad Pytel