Error: Calling brew cask install is disabled!

[dsnyder0pc]

I've been using the "community.general.homebrew_cask" module in Ansible to make sure that I have a set of casks installed on macOS laptops. This morning, my playbook started failing with this error message:

Error: Calling brew cask install is disabled! Use brew install [--cask] instead.

I can easily reproduce this issue by running "brew cask install" on the command-line:

$ brew cask install docker
Error: Calling brew cask install is disabled! Use brew install [--cask] instead.

Of course, installing via the command-line, I can switch to this:

$ brew install --cask --appdir=/Applications docker

But deprecating brew cask installis a breaking change for tools like Ansible that depend on a stable CLI interface from Brew. I'm sure that I'm not the only one who has encountered this issue. I'm curious to know how others have dealt with it.

[dsnyder0pc]

I've filed an issue with the Ansible team. Ideally, they should have addressed this while brew cask install was in deprecated state instead of waiting until it was completely disabled. I wonder if there's a good way for Ansible modules to catch deprecation warnings…

ansible-collections/community.general#1524

[Rylan12]

This is expected behavior. brew cask <command> was deprecated in favor of brew <command> --cask in Homebrew 2.6.0. Now that 2.7.0 has been released, they have been disabled. This was documented in the release notes and on the Homebrew blog in addition to the messages at the command-line. This is the typical cycle for breaking changes like this. First, we show a message saying "this will break here's how to fix it." Next, it stops working but with a message letting users know why it's not working (it was disabled) and with instructions for future use. Finally, these messages are totally removed. We generally move one step forward with each major/minor release.

The Homebrew maintainers don't have any connection with the anisble modules, so it's on the ansible folks to handle this. I agree, they should probably catch deprecation warnings. If they had, this likely wouldn't be an issue. Otherwise, they'll continue to be surprised when things break.

[rockdreamer]

Look, I'm all for keeping code maintainable but you'll agree with me that finding out that the ansible playbooks I spent a year writing at $work stopped working a couple of days before christmas is quite suboptimal.

I was hoping to go on some quite deserved holiday but I'm now in a position where I have to workaround this change in behaviour.

Pushing that aside, would it be reasonable to undo the change or at least reinstate a minimal brew cask install implementation to allow tools like ansible to keep working?

[MikeMcQuaid]

So you admit you're not a good maintainer. Glad we're on the same page.
It has everything to do with being a decent person.
I'm being blunt to someone who doesn't care about a community, but only his own ego.

@Sunhat Hi, I'm the project leader and I've been maintaining Homebrew for 11 years. @SMillerDev is a good maintainer on a project with millions of users. He's spending his free time working to help people and you respond with personal insults. You're now blocked on this project. You may find https://mikemcquaid.com/2018/03/19/open-source-maintainers-owe-you-nothing/ helpful in understanding how open source works.

Look, I'm all for keeping code maintainable but you'll agree with me that finding out that the ansible playbooks I spent a year writing at $work stopped working a couple of days before christmas is quite suboptimal.

@rockdreamer If you're reliant on Homebrew's behaviour not changing at $work without your intervention: I'd suggest disabling auto-updates. Your (presumably for-profit) workplace benefits from the volunteer time spent by Homebrew maintainers. Some of us in this thread are on holiday and spending our time trying to help folks here. Please bear that in mind.

Thanks!

[rockdreamer]

@MikeMcQuaid absolutely. Technically it's a scientific non profit, but for the sake of this discussion, I do get paid to do mostly unseen infrastructure work that enables the scientific part of the org to move forward (I'm the only person doing regular mac builds of ~4mln lines of C++) while work on brew is voluntary.

And you're right, I've grown a reliance on brew and ansible working together, with minor interventions required every now and then, and homebrew recipes getting updated and bugs getting fixed very quickly at the expense of having to keep all that code up to date. Homebrew has been a lifesaver for me, it helped me turn our mac build machines from a black hole of unknown stuff stitched together into a (mostly) reproducible set of scripts.

All I can add is a sincere thank you and @SMillerDev for acknowledging the problems this particular change's timing has caused, and for all the work that has made this reliance of mine possible.

[MikeMcQuaid]

@MikeMcQuaid absolutely. Technically it's a scientific non profit, but for the sake of this discussion, I do get paid to do mostly unseen infrastructure work that enables the scientific part of the org to move forward (I'm the only person doing regular mac builds of ~4mln lines of C++) while work on brew is voluntary.

Well thanks for doing your bit for pushing science forward ❤️

Homebrew has been a lifesaver for me, it helped me turn our mac build machines from a black hole of unknown stuff stitched together into a (mostly) reproducible set of scripts.

All I can add is a sincere thank you and @SMillerDev for acknowledging the problems this particular change's timing has caused, and for all the work that has made this reliance of mine possible.

Thanks again for the kind words ❤️

[emilecantin]

@Rylan12 @dsnyder0pc As seen here, there were only 20 days between the release of 2.6 (Dec. 1st) and the release of 2.7 (today). This is much shorter than the usual pace of one release every ~6 months. I think pinning the blame on the Ansible team is a little unfair; this deprecation notice was only visible for 20 days before it started crashing.

[geerlingguy]

@emilecantin - Considering many of the tools I use have release cycles that are either monthly or quarterly at the fastest, a 20-day deprecation-to-deletion cycle does seem fairly difficult to keep up with.

I don't blame anyone for cleaning up old code, but I would implore to try to figure out ways to give a longer deprecation time, at least 30-60 days, if not longer (I typically try to give 6 months).

[Rylan12]

You're right, this particular instance was a slightly shorter interval. Of course, our intention is not to break things for other users so I do apologize that this caused an issue.

[SMillerDev]

While I don't think a time range is feasible for homebrew, we could work on visibility here.

[emilecantin]

@SMillerDev I don't think anyone expects a specific time range, but when you do 2 releases in quick succession it'd be a good idea to stretch the usual "warn, then error" deprecation process to at least 2 or 3 releases.

Especially for something as basic as brew cask install.

[rogersmj]

No kidding...a core change like the install command going only 20 days from deprecation warning to failure is incomprehensible. That's not enough time (in most cases) for dependents to assess the change, plan and develop their changes, go through testing, release, and have the release propagate. I arrived here after a major framework I use failed when I was trying to install it on a new machine. Now I'm trying to figure out how to roll back Homebrew, which I've never done.

[SMillerDev]

This is much shorter than the usual pace of one release every ~6 months.

There was a year between homebrew 1.0 and 2.0 iirc, with 2.0 being released in February, so this timing isn't correct at all.

[gromgit]

I agree with @SMillerDev that deprecation visibility could be improved, but it strikes me that everyone filing complaints in this thread is using Homebrew in an automation context. Terminal users noticed this deprecation pretty much from the start; ISTR a couple of "hey, what's this all about" threads and issues weeks ago. In my experience, the only reliable way to draw attention to anything in an automation context...is to return an error code. (Most automation users really don't like to parse textual output.)

I think pragmatic way to improve deprecation visibility is for brew to return a specific and documented error code (say, 100) on every deprecated operation, in addition to what would normally be done in such a situation. Terminal users won't notice any difference, but scripting users would thus be alerted immediately, if they're Doing The Right Thing.

[Rylan12]

I run brew [verb] [noun]

This is exactly why the change was made. Now you can install casks and formulae the same way. There's no need to figure out which type it is, just brew install. install is a verb. cask is not.

When I'm installing a cask, I am saying "tell homebrew" (brew) "to install" (install) "this thing" (<thing>). Hence, brew install <thing>. brew <verb> <noun>.

[hakusaro]

@Rylan12 I totally get that, but I’m a primitive monkey who has muscle memory for one thing and not the other.

[SMillerDev]

You can be happy you only have to remember one thing from now on then 😁

[carlocab]

I, too, am a primitive monkey who always used to forget whether I needed to do brew install or brew cask install. Now, I don't need to. brew install just works.

[hakusaro]

I’m happy to hear it. I’m just pointing out that there is a crowd of people who are not adding their feedback here, and dismissing it because you don’t see it is irrelevant. I totally get the pains involved with maintaining decade old open source software and legacy shims for this and that. It’s constructive to tell users /why/ you’re changing something /in/ the message if you’re going to change it at all. If you want I’ll even pay you money to be more forthcoming about the issues that you’re facing as a development team @SMillerDev. I’ve tried to contribute to Homebrew in the past and it’s a tough bar to meet. You’re doing a lot. You can get a lot of empathy if you explain /why/ things change to the people who need to change workflows. There are a lot of Homebrew users who don’t even know that the project has versions! Those users get really upset and drop expletives when things break.

All I’m trying to say is that there are a silent majority of people who, at the end of 2020, are now getting irritated because they don’t know why something changed so rapidly. You can easily build empathy by communicating the reason behind your changes over the medium that they’re presented. If you don’t want empathy from users, that’s fine too. I just kinda figured you would like that.

It isn’t fun to say “hey, you’re kinda upsetting me and a lot of people with no context, please tell us why.” It’s clear to me that I’m in the minority on this forum. I’m having just as visceral and authentic of a reaction to being assassinated for not correctly typing the cask installation command as you’re having over upset users screaming “who moved my cheese?”

[MikeMcQuaid]

I appreciate this is a shorter turnaround that usual and I apologise for that. It is notable that none of you noticed the deprecation until it was disabled which makes me wonder if this wouldn't have just happened anyway had this not been disabled.

The best use of your time right now is to help test and provide feedback on the fix ansible-collections/community.general#1481

[emilecantin]

It is notable that none of you noticed the deprecation until it was disabled

In my case, the answer is simple: I use Ansible to setup my laptop when I re-install it; which is not very often. I got a new one last Friday so I dusted out my playbook; noticed these warnings last weekend when I was setting it up but thought they'd get fixed at some point; then everything broke on Monday when I tried to add another cask.

And in any case, Homebrew is a tool to install software. It's entirely possible (and I'd argue, common) to spend more than 20 days between invocations, causing people (like me) to miss the deprecation notice entirely.

[MikeMcQuaid]

And in any case, Homebrew is a tool to install software. It's entirely possible (and I'd argue, common) to spend more than 20 days between invocations, causing people (like me) to miss the deprecation notice entirely.

Yes but, it's also worth noting, the deprecation and disabling notices tell you what to run instead, a PR was open on the Ansible repository but not merged in time.

I don't think any open source project has done anything wrong here but I do find it hard to square that it's somehow Homebrew's fault than an unofficial wrapper for Homebrew wasn't updated in time?

Note: it takes a pretty large amount of (frankly boring) planning and effort as-is to do deprecations and write release notes at all.

[ginsburgnm]

@MikeMcQuaid I mean, at least for me; I didn't notice it due to the time of year 🤷‍♂️ (Given that almost 2 weeks after this was posted I'm just now seeing it lol) that being said; for my purposes, I'm not using homebrew for automation or using a wrapper, so the required cli change (that, as you pointed out, is given to you in a notice) wasn't a big deal.

I appreciate this is a shorter turnaround that usual and I apologise for that.

and

The best use of your time right now is to help test and provide feedback on the fix

👍 this is the right response, recognize that it was a bit unusual but move on.

[rockdreamer]

Most people I know don't notice deprecations like that immediately when using ansible. It's hard to see them in the wall of text that a mid-size playbook can generate.
I'm a fast reader and have the ability to pick up details from long text sequences, so I have a vague recollection of seeing a warning pop up in between the logs at some point and had made a mental note to check it at some point in the future, based on the assumption that most package managers avoid breaking their cli as it becomes de facto api for automation.

In that regard, I would like to point out two things:

• debian have two frontends: apt for humans and apt-get for scripts. apt will change more or less regularly and defaults to interactive mode, while apt-get is more stable and works better in non interactive mode. Would it be reasonable to have a switch in brew to deal with such a case?
• conan consider cli changes a breaking change and will do a 2.0 version where they will break cli compatibility. They have been very proactive about communicating this, more or less a year in advance and have introduced an environment variable to let people experiment with the new cli while still in the 1.x series. I don't know how brew treats version numbers, is it semantic versioning? Could brew treat cli changes as a major version number change?

[MikeMcQuaid]

EDIT: Re-reading this, I sound a little more aggressive than I intended; sorry about that.

Your apology is appreciated.

[emilecantin]

@MikeMcQuaid Apologies, that was really not my intention; see my edit.

[emilecantin]

@MikeMcQuaid To expand on my earlier reply: The "warn, then remove" pattern of doing deprecation is a good pattern in general, and a good way to notify users that something they use will change soon. The fact that automation tools sometimes hide warnings isn't ideal, but in a way, that's "not your problem". I don't think you should change anything there.

What should change, in my opinion, is the process for removing deprecated code. I think a simple check to see if sufficient time has elapsed since the original notice was released before removing the code would go a long way here. Just a PR title saying "Cleanup deprecated code; merge 4 months after release 2.6 at the earliest" would probably be enough. The exact duration is debatable; 6 months might be too long (?), 20 days is definitely too short.

Anyway, I don't think we need to get fancy with this, just take care to give users notice sufficiently in advance so they can adjust their scripts / muscle memory to the new way of doing things.

[MikeMcQuaid]

Just a PR title saying "Cleanup deprecated code; merge 4 months after release 2.6 at the earliest" would probably be enough. The exact duration is debatable; 6 months might be too long (?), 20 days is definitely too short.

I don't agree it's definitely too short but we can do better at communicating dates. We may consider a minimum of 1 month but I don't think we're going to stretch much longer than that.

[emilecantin]

I'd just like you to consider that at this point, Homebrew is very much a part of Mac infrastructure (it's one of the first things I install on any Mac, and I don't think I'm alone in this), and as such, other projects build upon it. 20 days is an awfully short time to realize there's a change in one of your dependencies, submit a PR, get it reviewed and publish a release... A month isn't much either.

I understand the desire to streamline code (hell, I'm currently refactoring some old code at my day job), but infrastructure projects aren't really the right place to "move fast and break things".

I don't think "communication" will help (not exactly sure what you have in mind here); the best way to notify users is through deprecation notices as you've done. Just make sure to give them a bit more time.

I really don't want to sound ungrateful for you guys' work. I'm expressing strong opinions here because I care about Homebrew; I've been using it since pretty much the beginning (switching over from MacPorts) and it's generally a pretty smooth experience. It "just works", and you guys can be proud of what you've built here.

[stevie400]

Hi, I know that this discussion already has quite a lot of comments, but I wanted to share how this impacted my teammates. I'm sorry if a new comment is not the most appropriate place to share this: I'm not familiar with the norms in GH discussions or in this particular repo, and this seems as good a place as any to share our experience.

We maintain a script that's used to configure developer machines. The script is idempotent and is run by both new hires and long-time employees when they get new machines, as well as by many people looking to solve various issues with their local set ups. This change broke our script, which is honestly sort of expected. I don't know if we would have noticed the deprecation if we had more time.

What was really painful for us was that this broke over the end-of-year holiday. Many of us were not working, but at least one person who was tried to run this script and hit problems with brew cask. This meant that the script owners, many of whom were not planning to work, had to jump in, figure out what was happening, and push a fix. Obviously, the problem itself was not serious and the fix was easy, but it was still an unwelcome surprise for the people who had to address it.

Thanks for reading, and for maintaining such an indispensable project.

[SMillerDev]

FYI: That sounds like you're duplicating some functions of homebrew-bundle, which is kept up to date by the homebrew maintainers. It might be worth looking into.

[stevie400]

Cool, that could be useful! The script does quite a bit beyond simply installing software.

[MikeMcQuaid]

I don't know if we would have noticed the deprecation if we had more time.

This is the most important thing to note here and thanks for admitting it.

Thanks for reading, and for maintaining such an indispensable project.

Thanks for the kind words!

[MikeMcQuaid]

The point has been made here so locking (and because all the drive-by 👎🏻s are demotivating, irritating and damaging to the motivation of our maintainers which is the main fuel for Homebrew). Here's what we're changing:

• we're not going to do major/minor releases less than 30 days apart
• we're printing when your Homebrew version changes and linking to the release notes every time we do
• we're printing the blog post link when we do major/minor releases

Here's what you (Homebrew users) need to do accordingly:

• read these major/minor blog posts, note any deprecations and plan to have them all addressed in 1 month in any tooling you use/maintain that wraps Homebrew
• do not ignore deprecation warnings printed to the console: these mean the command you have just run will likely not continue to run how it does in 1 month

We're not going to start adding longer periods for certain deprecations or not doing releases around the holidays (when our maintainers have more time rather than less time available).

Thanks for the kind words everyone who has shared them. A reminder that all Homebrew maintainers are unpaid volunteers working almost exclusively in their spare time and we also have jobs, families, etc. on top of maintaining Homebrew.

Those of you who respond to that with negativity, sniping or suggestions on how you could do it better: please either contribute to Homebrew enough that you're asked to join us as a maintainer and spend your time fixing these issues or read https://mikemcquaid.com/2018/03/19/open-source-maintainers-owe-you-nothing/ and please internalise that your negativity is literally killing open source.