Linuxbrew

[benjifisher]

Homebrew is now available for Linux: see https://docs.brew.sh/Homebrew-on-Linux

There are some differences:

• The preferred installation directory is /home/linuxbrew/.linuxbrew/Homebrew instead of /usr/local/Homebrew.
• There is no support for brew cask.
• Since brew is not installed in /usr/local/bin/, you need an extra step (modify PATH or symlink to /usr/local/bin/brew, for example) to use it conveniently.

I tried adding when: ansible_os_family == 'Darwin' to meta/main.yml, following Ansible: Conditional role dependencies, but that did not work. I guess I should update the README to recommend using the osx-command-line-tools role.

I am not sure whether to install gcc (as the role currently does) or leave that to the documentation. If we leave it to the documentation, then this should work without further changes on a wide variety of Linux distributions.

I tested this on Ubuntu 18.04 using Vagrant. I also tested on localhost (Pop!_OS 19.10) but it failed on the task of installing gcc with the python3 version of the error message reported at ansible/ansible#14468. I tried to debug that without success.

[benjifisher]

Note that defaults/main.yml already defines homebrew_brew_bin_path: "{{ homebrew_prefix }}/bin". I updated README.md to match this.

I also tried updating defaults/main.yml to match the documentation: homebrew_brew_bin_path: /usr/local/bin. This failed on the task "Force update brew after installation."

[geerlingguy]

I typically let playbooks set update_cache in their own pre_tasks rather than in a role itself. I would rather not add this parameter here for consistency's sake.

[benjifisher]

Done

[benjifisher]

Maybe a better solution is to remove this step entirely. As I said at the top, this is the only step that is specific to Debian. Subject to testing/debugging.

[geerlingguy]

Technically 'parent' (not grandparent) according to the registered var name?

[benjifisher]

More context:

- name: Check if homebrew grandparent directory is already in place.
  stat:
    path: "{{ homebrew_prefix | dirname }}"
  register: homebrew_prefix_parent
  check_mode: no

In defaults/main.yml we have

homebrew_install_path: "{{ homebrew_prefix }}/Homebrew"

My thinking is that

• homebrew_install_path is the "homebrew directory" (more precisely the "homebrew install directory")
• homebrew_prefix is the "homebrew parent directory"
• homebrew_prefix | dirname is the "homebrew grandparent directory"

so I do not think we want to replace "grandparent" with "parent" here. If you think this is confusing, then we can come up with something better.

Or maybe I should just change homebrew_prefix_parent to homebrew_grandparent?

[geerlingguy]

This should work on other Linux flavors too, right? For example, CentOS or Ubuntu?

Ideally, I want to get tests added for those platforms (though that requires restructuring the Travis CI tests a little so I can use base images like I do for my other roles like geerlingguy.apache for linux, versus Travis CI's macOS execution environments that I currently do, depending on the test matrix).

But doing this (naming the setup tasks Debian means that it wouldn't work for any other distros besides Debian (and I guess Ubuntu since it's keying on ansible_os_family).

[benjifisher]

See below.

[geerlingguy]

This should also work on Ubuntu the way it's currently structured. And with a couple tweaks mentioned elsewhere in this review, it should also work on EL (Red Hat / CentOS) and Fedora.

[benjifisher]

I guess I assumed that the platforms in the meta file were the same as ansible_os_family.

See below.

[benjifisher]

I will update this PR later this week (probably Thursday).

The first two comments look simple enough. (Famous last words. ;)

As for other Linux distributions, how much manual testing do you expect? Or should we delay this PR until we have some automated testing? I will also review the linuxbrew installation instructions and see what they say.

What is your preferred structure for including generic-Linux steps?

[geerlingguy]

@benjifisher - Maybe have a condition for if os family != Darwin, include linux tasks.

Also, no need to have the testing as part of this PR. I can work on that in a follow-on issue (it could be slightly strange since I'll be mixing two testing paradigms).

[benjifisher]

A few of the line comments dealt with relaxing the Debian restriction.

As I said at the top, one part of making this work in other Linux distributions is to remove the apt step that installs gcc. I moved that to documentation (README.md and tasks/playbook.yml).

I tested this with VirtualBox/Vagrant. When I first made this PR, I tested Ubuntu 18.04. Today, I tested with centos/7. For the record, I used

hosts:

vagrant ansible_host=127.0.0.1 ansible_port=2222

playbook.yml:

---
- hosts: vagrant

  pre_tasks:
    - name: Ensure that requirements are available.
      yum:
        name:
          - gcc
          - git
        state: present
        update_cache: yes
      become: yes
      when: ansible_os_family == 'RedHat'

  roles:
    - geerlingguy.homebrew

and the command

$ ansible-playbook -i hosts -u vagrant --private-key=.vagrant/machines/default/virtualbox/private_key playbook.yml

[benjifisher]

I added a link to https://docs.brew.sh/Homebrew-on-Linux#linuxwsl-requirements in README.md. For convenience, here is some of what it says there:

---

Linux/WSL Requirements

• GCC 4.7.0 or newer
• Linux 2.6.32 or newer
• Glibc 2.13 or newer
• 64-bit x86_64 CPU

Debian or Ubuntu

sudo apt-get install build-essential curl file git

Fedora, CentOS, or Red Hat

sudo yum groupinstall 'Development Tools'
sudo yum install curl file git
sudo yum install libxcrypt-compat # needed by Fedora 30 and up

---

Is the link good enough or should we add some of this information to README.md and/or meta/main.yml?

[geerlingguy]

Closing all issues in this repository in preparation for a migration to geerlingguy.mac—see #166