Brew: Automatically maintain ~/.Brewfile

[cweagans]

In the past, multiple people have requested that some kind of hooks functionality be added to Homebrew. This would unnecessarily complicate Homebrew in my opinion, but the rationale behind those requests has not been given adequate consideration IMO.

Rather than a generic hooks system, I would like to propose that Homebrew maintains ~/.Brewfile and keeps it up to date whenever new taps, formula, or casks are installed. This is the primary reason for all of the previous hooks requests, and I think it's a pretty legitimate one. This would allow anyone tracking their dotfiles in version control to simply add ~/.Brewfile and commit it whenever it changes.

Currently, the process to do this is a bit annoying, because after every brew command, I need to manually run brew bundle dump --file=~/.Brewfile --force. It works, but it's a kludge. I'm not sure that this is relevant to 90% of Homebrew users, but it also doesn't _harm_ anyone that doesn't want the functionality. They can simply ignore the file. I would also argue that anyone that currently has this file in place is probably already manually running the aforementioned command manually, and would be grateful for the automation.

I'm happy to implement this if a PR would be welcomed.

[MikeMcQuaid]

Homebrew has historically (and correctly in my opinion) never written any dotfiles. As you mention this is still possible with some manual work that I think is more desirable and could be wrapped with a script or function that calls brew bundle dump after each brew run. Sorry but thanks.

[cweagans]

I am not the first to suggest this, nor will I be the last. I really don't understand your rationale here, but would you be open to an opt-in approach via an environment variable or something? It's extremely unlikely that I'm going to write a script that wraps all of the brew commands and run brew bundle dump after some of them when it's a problem that could be very trivially solved in Homebrew itself.

[MikeMcQuaid]

I am not the first to suggest this, nor will I be the last.

Can you link to the other suggestions? Thanks!

It's extremely unlikely that I'm going to write a script that wraps all of the brew commands and run brew bundle dump after some of them when it's a problem that could be very trivially solved in Homebrew itself.

That's up to you.

[vitorgalvao]

It's extremely unlikely that I'm going to write a script that wraps all of the brew commands and run brew bundle dump after some of them when it's a problem that could be very trivially solved in Homebrew itself.

Solving this in HB itself is less trivial than the alternative:

```
newbrew() {
brew ${@}
brew bundle dump --file=~/.Brewfile --force
}

[cweagans]

Can you link to the other suggestions? Thanks!

I found these four very quickly. Hard to track them down because of the repository changes, but note that you (@MikeMcQuaid) mentioned in https://github.com/Homebrew/brew/issues/2202#issuecomment-282584704 that it had been requested a few times before, so this can't be news to you.

• https://github.com/Homebrew/brew/issues/3716
• https://github.com/Homebrew/brew/issues/2202
• https://github.com/Homebrew/legacy-homebrew/issues/47393
• https://github.com/Homebrew/legacy-homebrew/issues/24907

Solving this in HB itself is less trivial than the alternative:

Not if you want to do it correctly. It's not necessary to dump the Brewfile after brew list for instance. Personally, I would rather not incur the 2 second penalty on _every_ brew command.

Yes, this can be solved outside of Homebrew, but why should it not be Homebrew's issue? It's a point of friction that can be solved with zero negative consequences.

[vitorgalvao]

Not if you want to do it correctly. It's not necessary to dump the Brewfile after brew list for instance. Personally, I would rather not incur the 2 second penalty on _every_ brew command.

That is still trivial:

newbrew() {
  local dump_commands=('install' 'uninstall') # Include all commands that should do a brew dump
  local main_command="${1}"

  brew ${@}

  for command in "${dump_commands[@]}"; do
    [[ "${command}" == "${main_command}" ]] && brew bundle dump --file="${HOME}/.Brewfile" --force
  done
}

but why should it not be Homebrew's issue?

Adding a feature does not just mean writing the code. It means maintaining it (code) and supporting it (issues); dealing with every other thing that breaks because of it; and considering it when weighing other new features that may clash with it (even if in usability).

That’s why it’s important that a feature request passes the “relevant to 90% of users” barrier. Maintainers have limited time, so where that time is spent needs to be carefully considered.

[cweagans]

Adding a feature does not just mean writing the code. It means maintaining it (code) and supporting it (issues); dealing with every other thing that breaks because of it; and considering it when weighing other new features that may clash with it (even if in usability).

Yeah, I'm aware. I maintain a widely used project as well.

IMO, it still doesn't make sense to make each individual user that is affected by this problem solve it individually, even if the method for doing so is easy.

[MikeMcQuaid]

IMO, it still doesn't make sense to make each individual user that is affected by this problem solve it individually, even if the method for doing so is easy.

It does make sense in the case where it's relatively easy to do so, users cannot currently agree on how this should behave and we have a very low number of requests proportional to Homebrew (or even brew bundles) users.

[ilovezfs]

Another option: have launchd run brew bundle dump for you once an hour and forget about this forever.

[cweagans]

TIL kludgy workarounds are an acceptable substitute for 20 lines of well tested, widely used code. I seriously cannot understand that mindset. You have refused to add ways for users to extend Homebrew, and you have refused to add specific functionality that users would add in third party extensions if they were able. You have essentially mandated that kludgy workarounds are the _only_ way to get this functionality, and that's really not a great situation.

users cannot currently agree on how this should behave

If that's the barrier, then reopen this issue and let users discuss it. Tweet it out and ask for feedback. People aren't going to see/engage with it if it's closed.

a very low number of requests proportional to Homebrew

I would argue that literally anyone using brew bundle would benefit from this feature, even if they haven't explicitly requested it.

[ilovezfs]

@cweagans Please read, or re-read, our Code of Conduct and adjust your future communication accordingly.

[MikeMcQuaid]

TIL kludgy workarounds are an acceptable substitute for 20 lines of well tested, widely used code.

Wrapping a Unix tool with a Unix shell script is an acceptable substitute for an unknown quantity or quality of unwritten code that would be used by a minority of Homebrew's users.

You have refused to add ways for users to extend Homebrew

Untrue. Users can use and build external commands which can be shared in taps (along with formulae).

If that's the barrier, then reopen this issue and let users discuss it.

That's not how we run our issue tracker, run yours how you choose.

I would argue that literally anyone using brew bundle would benefit from this feature, even if they haven't explicitly requested it.

I use, have contributed more to it than anyone else and have maintained longer than anyone else both this repo and Homebrew/homebrew-bundle. I've also rolled out Homebrew/homebrew-bundle to hundreds of developers in an organisation who use it daily and built tools on top of it used by many other organisations. I would not use this feature and most of the aforementioned folks would not either.

Finally, I wish I'd listened to my gut earlier and, like @ilovezfs has done, pointed you to our Code of Conduct. Unfortunately you seem unable to conduct yourself in a polite fashion so I'm uninterested in continuing this conversation. I hope that we're able to work together on a PR or issue in future but please note that continued violations of our Code of Conduct will result you being blocked from the Homebrew organisation.