Add ability to provide context to what is being installed/updated

[ctaintor]

We are using Brewfiles to set up people's machines and we want to give context to what we are installing. The current setup is not ideal for it so I wanted to raise some issues we have and some potential solutions.

What we want to achieve:

• as things are installed/checked/updated, give people context on what the thing is. For example, if we are installing the VS Code Cask, we might want to say "Setting up our standard development IDE – Visual Studio Code". This would then be followed by Using Visual Studio Code (if it's installed/etc) or "Installing ", depending.
• we know that some things take a while to install if it's the first install and could take a while if it's an update. We'd want to either have a line that says that or in the context-setting message, we'd like to put "(this could take 5-10 minutes)"

for the latter, one option could be to just output what brew is doing, but unfortunately I can't e.g. run brew bundle without --verbose and see any of the result. In other words, passing --quiet might work. But when I think about it more, I think just having the simple ability to output a message before the next action happens is more flexible.

My proposal:

• add a new message method to the DSL which takes a string
• when that command is run, it just prints the message

Happy to send a PR if this is wanted! also happy to take suggestions

[MikeMcQuaid]

• For example, if we are installing the VS Code Cask, we might want to say "Setting up our standard development IDE – Visual Studio Code". This would then be followed by Using Visual Studio Code (if it's installed/etc) or "Installing ", depending.

Rather than having everyone set a custom message here: would using the desc in the cask be sufficient?

• We'd want to either have a line that says that or in the context-setting message, we'd like to put "(this could take 5-10 minutes)"

How would you decide how long this is and would it be set for every message?

---

I've not heard anyone else asking for this so, while not strongly opposed, I can't help but feel like a wrapper script for this (e.g. https://github.com/github/scripts-to-rule-them-all/blob/HEAD/script/bootstrap#L10-L15) might be a better fit? You could potentially use multiple Brewfiles this way, too.

What might help us brainstorm better together here: what's the problem you/your users experience today? Figuring out the problem rather than going straight to the solution may help here.

Thanks!

[ctaintor]

Rather than having everyone set a custom message here: would using the desc in the cask be sufficient?

I thought of this. While it could be interesting, the desc is pretty generic and would only be contextually interesting if it were an internal formula/cask. (For example – for Visual Studio Code, I might want to say "Setting up our standard development IDE – Visual Studio Code" rather than "Open-source code editor".) It might be interesting though to allow for the Brewfile to override the desc. In other words, you could have a flag for bundle which would always print the desc and then on a per-cask/formula level you could override the desc or turn it off? However, given the fact that it's likely that few desc's would be useful in this context, I figured just having a passthrough to puts would be simpler.

How would you decide how long this is and would it be set for every message?

In my exact case, I have 5-10 internal things which are installed and none of them have bottles. Generally any Python CLI takes a while due to rpds_py being a dependency of the popular requests library... and it requires rust... For the 2 python CLIs, I can say that it may take up to 10 minutes, meaning that people won't immediately think things are broken if it waits. For the node CLIs it would be closer to like "up to 2 minutes" and the go CLIs don't require anything.

I can't help but feel like a wrapper script for this (e.g. https://github.com/github/scripts-to-rule-them-all/blob/HEAD/script/bootstrap#L10-L15) might be a better fit? You could potentially use multiple Brewfiles this way, too.

We are actually doing something like this already (a CLI which does the brew bundle calling, multiple brewfiles, etc). We could (and should!) use brew check to eliminate messaging when nothing needs to be done. But if something does need to be updated or installed, making that an experience with good output gets close to reimplementing brew bundle 😓

[ctaintor]

It's probably also worth mentioning that we are using brew bundle in a way where the end user knows we're using it – but they aren't running brew bundle themselves. They are instead thinking "I want to have my machine set up for standard development" and "I want to have my machine set up for node development"

[MikeMcQuaid]

Ok. Will leave this open for now and see if anyone else chimes in. If not: the stalebot will get it. Would want to see at least one other person see the need for this before we carry the code forever.