Interest in support for groups and/or Mac/Linux platform awareness in homebrew-bundle?

[joehorsnell]

Firstly, a huge thanks @MikeMcQuaid and team for your incredible efforts on Homebrew.

Now to my question. Our team uses a mixture of Mac and Linux for development. Since the merge of Linuxbrew into Homebrew, and given the large number of formula that are available on both platforms, Homebrew has become (IMO) a very compelling choice for cross-platform development environment setup. This is made even more appealing with the convenience of homebrew-bundle.

Obviously however there are major differences between the platforms, not least Casks on macOS. These differences can be handled fairly simply by using different Brewfiles and controlling which ones are installed outside of homebrew-bundle, bit I was thinking it might be quite convenient and powerful if there was native support for groups and/or awareness of which platform is being used in homebrew-bundle?

I can see there have been some previous suggestions and discussions around groups.

Would you have any interest in a PR to provide support for arbitrary groups within a Brewfile and/or a mechanism for specifying which platform should be targeted?

Something along the lines of:

$ cat Brewfile
brew "rbenv"
brew "ruby-build"
.
.
platform :macos do
  cask "google-chrome"
  cask "virtualbox"
end

The group idea as suggested in #175 and #248 could also be useful (for example) to install common tooling for development and CI (in say a Docker image build), then have additional development-only tools in another group and even have 'optional' packages in another group?

As mentioned above, this can obviously be achieved outside of homebrew-bundle using separate files, but that requires custom logic and tooling to control which files are installed and when, whereas this could make it simpler by allowing all your project's dependencies to be defined in once place, but conditionally installed based on context, much like with Bundler and Gemfiles.

Based on your general experience with Homebrew, do you think this would work in practice and if not what issues do you foresee?

[issyl0]

I’ve had success with one Brewfile for both MacOS and Linux of the form:

if OS.mac?
  cask "google-chrome"
  cask "aws-vault"
else
   brew "some-linux-formula"
end

But the elegance of this could definitely be improved!

Your approaches sound interesting, particularly the platform :macos one - thanks! Or, potentially skipping installing Casks entirely if we’re on Linux?

I’d be happy to help review a PR. 😄

[MikeMcQuaid]

Firstly, a huge thanks @MikeMcQuaid and team for your incredible efforts on Homebrew.

Thanks for the kind words!

Obviously however there are major differences between the platforms, not least Casks on macOS.

This is why currently Linux is unsupported (see the README). For it to be supported I'd want to see the following:

• CI added for Linux
• cask and mas gracefully handled on Linux (suggestion that they are unconditionally skipped with the Skipper: https://github.com/Homebrew/homebrew-bundle/blob/master/lib/bundle/skipper.rb)
• Mac and Linux code in Homebrew/homebrew-bundle itself is separated by classes hierarchies (like Homebrew/brew: https://github.com/Homebrew/brew/blob/master/Library/Homebrew/extend/os/mac/keg.rb) not if OS.mac?
• The documentation is updated accordingly

Would you have any interest in a PR to provide support for arbitrary groups within a Brewfile and/or a mechanism for specifying which platform should be targeted?

I'd rather see @issyl0's approach (if OS.mac? or if OS.linux?) rather than adding a DSL for now.

The group idea as suggested in #175 and #248 could also be useful (for example) to install common tooling for development and CI (in say a Docker image build), then have additional development-only tools in another group and even have 'optional' packages in another group?

I would rather not see this. I'm unconvinced of the usefulness and e.g. HOMEBREW_BUNDLE_BREW_SKIP allows the user to already customise this behaviour to avoid installing select packages.

---

This all said: thanks for opening the issue; I'd love to see more work in this direction.

[joehorsnell]

Thanks for your responses @issyl0 and @MikeMcQuaid.

@issyl0 - that's a good suggestion (if OS.mac?), thanks. I'll use that in the short term.

Good points @MikeMcQuaid and I agree that Linux would need to be officially supported before adding any features to homebrew-bundle that are platform-aware. I must admit, I hadn't realised that it wasn't officially supported.

I also wasn't aware of HOMEBREW_BUNDLE_BREW_SKIP, but that looks like it could also be used. Again though, the control of it is outside of homebrew-bundle, so requires building that logic and what your various groups are externally, rather than just being able to provide command-line arguments to specify the groups, the meaning of which is defined inside the Brewfile.

Anyway, I'll give it some thought and given that we are planning to use homebrew-bundle on Linux, I will try and take a look at adding official support for it.

[jacobbednarz]

I think this concept is a good one, thanks for re-raising it now Linuxbrew is getting some traction.

My biggest caveat to this work would be the amount of stuff that doesn't have a Linux alternative (mas, cask) and how we would maintain a degraded experience if someone used unsupported functionality on the wrong OS. Example, not using the correct OS and just dumping everything in a single Brewfile.

I'm with @MikeMcQuaid regarding the groups and I can't really see a use at the moment outside of the OS specific stuff which I think is fine as if OS.mac for now.

[colindean]

I'm with @MikeMcQuaid regarding the groups and I can't really see a use at the moment outside of the OS specific stuff which I think is fine as if OS.mac for now.

☝️

My biggest caveat to this work would be the amount of stuff that doesn't have a Linux alternative

I think this will nearly always be a barrier until the Linuxbrew core tap reaches some level of parity with homebrew-core.

If homebrew-bundle were to expand to some generic manifest of various package management systems – e.g. brew and cask as Homebrew-specific things with operating system-level things like mas, apt, snap, etc., as per-OS packages accessible through if OS.mac or some convoluted thing like if OS.pkgmgr.has_apt? or ecosystem-level things like pip, npm, cargo, etc. accessible through if OS.pkgmgr.has_cargo? – then I could see this getting both really easy for bundle while shifting the complexity to the user, but then it basically just becomes some ridiculous shellscript wrapper around tools that already have good-enough interfaces. I don't see homebrew-bundle going that way anytime soon. It's not our competency nor do I think it's worth going in that direction anytime soon.

[MikeMcQuaid]

I also wasn't aware of HOMEBREW_BUNDLE_BREW_SKIP, but that looks like it could also be used. Again though, the control of it is outside of homebrew-bundle, so requires building that logic and what your various groups are externally, rather than just being able to provide command-line arguments to specify the groups, the meaning of which is defined inside the Brewfile.

Sorry, to be more specific: I don't mean that you should have to set that on Linux but that on Linux a mas or cask should always just show Skipping without any need for users to do this. The Skipper should have a Linux or macOS subclass that results in essentially (in pseudocode) skip if type == "cask|mas" if OS.linux?

If homebrew-bundle were to expand to some generic manifest of various package management systems – e.g. brew and cask as Homebrew-specific things with operating system-level things like mas, apt, snap, etc., as per-OS packages accessible through if OS.mac or some convoluted thing like if OS.pkgmgr.has_apt? or ecosystem-level things like pip, npm, cargo, etc. accessible through if OS.pkgmgr.has_cargo? – then I could see this getting both really easy for bundle while shifting the complexity to the user, but then it basically just becomes some ridiculous shellscript wrapper around tools that already have good-enough interfaces. I don't see homebrew-bundle going that way anytime soon. It's not our competency nor do I think it's worth going in that direction anytime soon.

I actually think it would be good for someone to do this but I think it should be a separate project. Personally I'd hate to see a project Brewfile used as a justification for people on e.g. Ubuntu to use Linuxbrew's versions of stuff provided by the system package manager. There's still nothing like Brewfile, as far as I've seen, on Linux that dictates "you need X package" and I do think that would be a useful thing to have.

[joehorsnell]

Thanks for your responses everyone 👍. Interesting points made.

Regarding the "platform awareness" suggestion, just to clarify - my main thinking here was to be able to handle (within homebrew-bundle) the fact that, while a great number of packages have identically-named formula in both homebrew-core and linuxbrew-core (eg rbenv, ruby-build, tmux, jq to name just a handful we use), some things on macOS are a cask (eg java11 through caskroom/versions) while the Linux equivalent to achieve the same goal (of having a Java 11 JDK installed) is the openjdk@11 formula.

I didn't envisage that homebrew-bundle would in any way be a wrapper for other OS-specific package management tools (such as apt) - in fact quite the opposite. As I said in my initial comment, one of the main attractions (for me) of Homebrew and homebrew-bundle is the fact that it provides a uniform interface for installing dependencies on different platforms.

In any case, it looks like the first step to any future discussion would be to add official support for Linux to homebrew-bundle as is, which I think would be uncontroversial? ie add CI, make it DoTheRightThing when encountering casks, etc.

If so, I'll try and take a look at that soon. Feel free to close this issue for now, or I'll close it unless anyone else has anything to add for now?

Cheers again.

[MikeMcQuaid]

As I said in my initial comment, one of the main attractions (for me) of Homebrew and homebrew-bundle is the fact that it provides a uniform interface for installing dependencies on different platforms.

We agree. I think this, to me, is the main argument against having something that implies "install X on macOS and Y on Linux" as installing Y may often be better suited to the system package manager.

In any case, it looks like the first step to any future discussion would be to add official support for Linux to homebrew-bundle as is, which I think would be uncontroversial? ie add CI, make it DoTheRightThing when encountering casks, etc.

Yup!

If so, I'll try and take a look at that soon. Feel free to close this issue for now, or I'll close it unless anyone else has anything to add for now?

Sounds good.

Cheers again.

And to you, thanks again @joehorsnell!

[MikeMcQuaid]

For it to be supported I'd want to see the following:

I've done all this in https://github.com/Homebrew/homebrew-bundle/pull/533

[joehorsnell]

Nice one @MikeMcQuaid, cheers. I was on holiday last week and was going to take a look at this this week, but you beat me to it!

[MikeMcQuaid]

You're very welcome @joehorsnell!