Error: undefined method `caskroom' for Hbc:Module

[agross]

$ brew cu
Error: undefined method `caskroom' for Hbc:Module
/usr/local/Homebrew/Library/Taps/buo/homebrew-cask-upgrade/lib/extend/hbc.rb:1:in `<top (required)>'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3_2/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3_2/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/usr/local/Homebrew/Library/Taps/buo/homebrew-cask-upgrade/lib/bcu.rb:6:in `<top (required)>'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3_2/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3_2/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/usr/local/Homebrew/Library/Taps/buo/homebrew-cask-upgrade/cmd/brew-cu.rb:32:in `<top (required)>'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3_2/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3_2/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/usr/local/Homebrew/Library/Homebrew/utils.rb:18:in `require?'
/usr/local/Homebrew/Library/Homebrew/brew.rb:105:in `<main>'

$ brew --version
Homebrew 1.6.7-56-g9ebcef7
Homebrew/homebrew-core (git revision 512758; last commit 2018-06-09)

$ brew cask --version
Homebrew-Cask 1.6.7-56-g9ebcef7
Homebrew/homebrew-cask (git revision c97f0; last commit 2018-06-09)

$ brew irb
=> Interactive Homebrew Shell
Example commands available with: brew irb --examples
irb(main):001:0> Hbc.methods.grep /cask/
=> []

[agross]

A quick git-bisect start 9ebcef78 61bcec42 in /usr/local/Homebrew shows this is the breaking commit.

[7k50]

+1

[ycaille]

Same issue today!

[sprainbrains]

Same issue to!

[jenhsun]

some issue here.

[jenhsun]

@goodwillcoding You are correct. Many thanks.
Let me write down the way I rephrase it.

go to /usr/local/Homebrew/Library/Taps/buo/homebrew-cask-upgrade/lib/extend/hbc.rb
and change the first line CASKROOM= Hbc.Caskroom to CASKROOM=Hbc::Caskroom.path

That's it.

[ondrejfuhrer]

@jenhsun You have a typo there and people are copying it 😆 Please change CASROOM to CASKROOM 😉

[jenhsun]

@ondrejfuhrer Oops. Thanks.

[KarlZeo]

@buo Please fix it.Thanks.

[buo]

This issue was fixed by PR #96. Thanks.

[kil0rome0]

Tried what @jenhsun added however that was already in place. Still same error.

Error: undefined method path' for Hbc::Caskroom:Module /usr/local/Homebrew/Library/Taps/buo/homebrew-cask-upgrade/lib/extend/hbc.rb:1:in <top (required)>'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3_2/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in require' /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3_2/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in require'
/usr/local/Homebrew/Library/Taps/buo/homebrew-cask-upgrade/lib/bcu.rb:6:in <top (required)>' /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3_2/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in require'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3_2/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in require' /usr/local/Homebrew/Library/Taps/buo/homebrew-cask-upgrade/cmd/brew-cu.rb:32:in <top (required)>'
/usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3_2/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'

╰─ brew --version
Homebrew 1.6.7
Homebrew/homebrew-core (git revision 05550; last commit 2018-06-12)

╰─ brew cask --version
Homebrew-Cask 1.6.7
Homebrew/homebrew-cask (git revision 16850; last commit 2018-06-11)

╰─ brew irb
==> Interactive Homebrew Shell
Example commands available with: brew irb --examples
irb(main):001:0>

[jenhsun]

@karlrabe Go to the hbc.rb file and make sure there is no strange <<< or === line on it, then restart your terminal.

[ondrejfuhrer]

Hey, @karlrabe please run this #97 (comment)

[reitermarkus]

Hi all, Homebrew maintainer here.

Are you all aware that brew cask upgrade has been available since November?

If so, what is it still lacking that this project does better?

[ondrejfuhrer]

Hey @reitermarkus

I can of course speak only for myself and I am aware that this option is out there. If I put aside much nicer "UI", the main differences for me are:

1. Easier usage - I don't have to run more commands to know what I'm going to update and the updating itself (I run only brew cu instead of brew cask outdated and brew cask upgrade)

2. Better handling of auto-update casks. I.e. this morning:
   After funning brew cu -ac
   

After running brew cask outdated

After running brew cask outdated --greedy

So in this case I either update only plex-media-player or all "latest" and auto-update apps. That does not happen in brew cu

Those are the biggest advantages for me right now.

[reitermarkus]

@ondrejfuhrer, definitely agree with 2. I personally don't think auto_updates is useful, but that's another discussion.

Not sure I understand 1 exactly. You also don't have run brew cask outdated before brew cask upgrade.

[jenhsun]

@reitermarkus We use brew cu because we all know what brew cask upgrade can or can't do for us. And that's why brew cu popularity is huge.

Most of the time I just run brew update && brew upgrade && brew cu -ayc and move on.

[reitermarkus]

we all know what brew cask upgrade can or can't do for us.

Well I don't, that's why I am asking.

[jenhsun]

@reitermarkus try brew update && brew upgrade && brew cu -ayc. You'll happy about it.

In brief,

• brew update already replace brew cask update
• brew cu replace brew cask outdated && brew cask upgrade in order to show better terminal view.

That's all.

[ondrejfuhrer]

@reitermarkus
Well, in this case (google-chrome) it is useful. Of course, you will get the same version just by running it and leave the updating to the app. But the cask also have the version written inside, so you end up with inconsistency between the installed version detected by brew and the actual installed version.
But of course, that it super minor thing since the end is the same - you have up-to-date software which should be the goal.

Regarding the first one @jenhsun already touched the surface. Of course I don't have to run outdated before, but I want to know, what I'm going to update before I start to do it. Why? For example I always quit the application before I update in order to have the update smoother.

What brew cu brings here very nicely is the overview, what are the outdated casks and then you just confirm or not confirm, that you want to update. And you don't have to run other command to do so.

I hope that clarifies my point of view here 🙂

[reitermarkus]

then you just confirm or not confirm

That part at least will never be possible. Homebrew is non-interactive by design. However we would definitely accept a PR which provides a nicer overview.

[ondrejfuhrer]

Homebrew is non-interactive by design

I get that decision. Just to throw an idea here, would it not be possible as opt-in? I.e. running something like brew cask upgrade --interactive would bring that functionality in?

[reitermarkus]

brew cask upgrade --interactive

I don't think so, because this is again the functionality of brew cask outdated followed by either brew cask upgrade or not.

[F30]

@reitermarkus My reasoning is similar to what @ondrejfuhrer described: I basically want to include apps that have auto_updates true in the upgrade. There are two main reasons for that (see also #53):

1. Upgrading as much as possible in one go, without having to open the apps
2. Having additional authenticity checks using checksums from a third-party source

As far as I can see, I could kind of get that using brew cask upgrade --greedy, but that'll always include version :latest apps. These don't really fit nicely into the concept described above, but they're a reality and re-downloading them all the time is not an efficient solution.

Since #53, brew cu allows to include apps with auto_updates true while excluding those with version :latest, which is not ideal, but viable. I don't think this is possible with brew cask upgrade.

[Fischmuetze]

Same here since today - discussed solutions doesn't work

$ brew cu ==> Options Include auto-update (-a): false Include latest (-f): false ==> Updating Homebrew Error: uninitialized constant Hbc::SystemCommand Did you mean? SystemCommand /usr/local/Homebrew/Library/Taps/buo/homebrew-cask-upgrade/lib/extend/hbc.rb:56:in brew_update'
/usr/local/Homebrew/Library/Taps/buo/homebrew-cask-upgrade/lib/bcu.rb:20:in process' /usr/local/Homebrew/Library/Taps/buo/homebrew-cask-upgrade/cmd/brew-cu.rb:34:in <top (required)>'
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in require' /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in require'
/usr/local/Homebrew/Library/Homebrew/utils.rb:18:in require?' /usr/local/Homebrew/Library/Homebrew/brew.rb:93:in

'

$ brew --version
Homebrew 1.7.1-10-g6027683
Homebrew/homebrew-core (git revision 0ce9a; last commit 2018-07-24)

$ brew cask --version
Homebrew-Cask 1.7.1-10-g6027683
Homebrew/homebrew-cask (git revision 59eba; last commit 2018-07-24)`

tried to remove and reinstall via
brew tap buo/cask-upgrade
but this would not help

[schliflo]

@Fischmuetze this is because of #103 - which will be fixed when #104 is merged

[vitorgalvao]

I basically want to include apps that have auto_updates true in the upgrade. (…) As far as I can see, I could kind of get that using brew cask upgrade --greedy, but that'll always include version :latest apps.

I’ve seen other people that want the upgrade to include auto_updates true but not version :latest. It’s the exact opposite of what you should want, and you’re letting supposed download time get in the way. Add && exit and walk away.

version :latest are exactly the casks we can’t control the version of. By excluding those from the upgrade, you’re letting them sit in a permanently outdated mode. That’s may not be too bad, and we try to remove :latest whenever possible.

When you upgrade auto_updates true casks, however, you may be getting a downgrade. Naturally, we can only upgrade you to the latest version in the cask, and that may be earlier than what you have (it’s common for upstream to release updates selectively).

Even if you’re upgrading to the correct version, you’re also spending the bandwidth to download auto_updates true casks before you need them (and again, don’t forget it might be an accidental downgrade, wasting further), and you may not even use that version. So I don’t really get the argument: you want to save time/bandwidth by not upgrading version :latest, but then you’re wasting it on upgrading auto_updates true. If anything, you should always do the reverse.

Having additional authenticity checks using checksums from a third-party source

Please don’t trust us as “additional authenticity checks”, because we’re not:

It’s impossible for us to know when an app was tampered with and we need to set expectations accordingly.

The sha256 verification we do should always be viewed as an integrity check (i.e. did it download correctly), not a security (let alone authenticity) feature. The one feature we added that provided true security (quarantining) might need to be rolled back, because the way Apple went about it is all good intentions and bad implementation.

[F30]

It’s the exact opposite of what you should want, and you’re letting supposed download time get in the way. Add && exit and walk away.

Thanks for telling me what I should want.

When you upgrade auto_updates true casks, however, you may be getting a downgrade. Naturally, we can only upgrade you to the latest version in the cask, and that may be earlier than what you have (it’s common for upstream to release updates selectively).

That assumes that I actually have automatic updating enables within the applications. For most apps, this can be disabled and I consequently do that. For others, Homebrew Cask is usually pretty quick at updating the Cask. In multiple years of doing upgrades like this, I've never encountered any problematic downgrades, though I see the theoretical possibility.

Even if you’re upgrading to the correct version, you’re also spending the bandwidth to download auto_updates true casks before you need them (and again, don’t forget it might be an accidental downgrade, wasting further), and you may not even use that version. So I don’t really get the argument: you want to save time/bandwidth by not upgrading version :latest, but then you’re wasting it on upgrading auto_updates true.

I might have limited bandwidth or no time to wait for an upgrade by the time I "need" an app. Most apps don't release new versions that often, so the time to download some releases I won't use seems rather well-wasted. Downloading the version :latest applications over and over, on the other hand, is really annoying – repeatedly (every few days). I am well aware that I need a different solution to keep these up to date, be it manual updates or an app's own mechanism (if it also has auto_updates true).

The sha256 verification we do should always be viewed as an integrity check (i.e. did it download correctly), not a security (let alone authenticity) feature.

I said it is an additional check. I can at least be sure that I get the same download as the person who updated the cask (and other Homebrew Cask users). It obviously won't protect against long-term compromises of an app's download server.

I'm not saying that my strategy is a perfect model, but given the various constraints it's the best I can achieve and working quite well for me.

[vitorgalvao]

Thanks for telling me what I should want.

I meant no offence, and apologise if I did offend.

That assumes that I actually have automatic updating enables within the applications. For most apps, this can be disabled and I consequently do that.

Fair. I hadn’t considered that.

I've never encountered any problematic downgrades, though I see the theoretical possibility.

I can guarantee downgrades have happened, but it’s unlikely they have been problematic.

I said it is an additional check.

So did I. The point is I’m asking you to not trust those at all from a security standpoint. It’s not their goal.

I can at least be sure that I get the same download as the person who updated the cask

And Travis CI. But that is fine; that’s exactly what they’re for, integrity checks.

I'm not saying that my strategy is a perfect model, but given the various constraints it's the best I can achieve and working quite well for me.

Thumbs up to that. Again, I had no intention to belittle your method.