Closed agross closed 6 years ago
A quick git-bisect start 9ebcef78 61bcec42
in /usr/local/Homebrew
shows this is the breaking commit.
+1
Same issue today!
Same issue to!
some issue here.
@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.
@jenhsun You have a typo there and people are copying it 😆 Please change CASROOM
to CASKROOM
😉
@ondrejfuhrer Oops. Thanks.
@buo Please fix it.Thanks.
This issue was fixed by PR #96. Thanks.
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>
@karlrabe Go to the hbc.rb file and make sure there is no strange <<< or === line on it, then restart your terminal.
Hey, @karlrabe please run this https://github.com/buo/homebrew-cask-upgrade/issues/97#issuecomment-396161489
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?
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:
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
)
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.
@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
.
@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.
we all know what
brew cask upgrade
can or can't do for us.
Well I don't, that's why I am asking.
@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.
@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 🙂
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.
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?
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.
@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):
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
.
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
@Fischmuetze this is because of #103 - which will be fixed when #104 is merged
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 usingbrew cask upgrade --greedy
, but that'll always includeversion :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.
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 upgradingversion :latest
, but then you’re wasting it on upgradingauto_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.
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.