brew cask add upgrade/outdated/pin/unpin #1523
Conversation
|
Not a Homebrew Cask maintainer: I don't think |
|
Don't have time to review this now, pinging @Homebrew/cask. |
|
@MikeMcQuaid The problem is those doesn't have auto-upgrade, like wireshark/calibre/etc. I don't think add |
|
Personally I think such a DSL and widespread use of it is important before these commands should be included. |
This already exists: |
@jawshooah Nice. No objections from me, then, if these commands properly handle this DSL 👍 I was going to whine about how most of my casks have this DSL flag missing but I'll submit a PR to add them instead 😉. Be the change(set) you want to see in the world! |
|
@jawshooah Thanks very much. I'll include its process in next commit. Not sure why the CI failed, the failed |
|
@reitermarkus Could you look into the test failure? Pretty sure it's a regression from the test refactoring. |
Thank you! When an app can auto-update, though, it also means it has to have an appcast somewhere, and we try to have the least amount of casks possible with the former but not the latter. Our documentation on As for the PR itself, something worries me a bit. I think HBC’s Apart from it absolutely needing to respect You have a commercial app at version
|
|
Made 2 more commits, consider auto-updates ( by default will no more upgrade them, but you can ignore it too ) , and can upgrade specified packages now. Add version info to pinned marker for future. |
I don’t understand your point at all. Why would we need multiple uninstallation instructions? We don’t.
That would make the DSL needlessly complicated for everyone with no gain. It would annoy both users and maintainers. The point here is that users can upgrade or not when they want, not needlessly pin them without their input.
Yes, exactly, so things can be done the right way. There’s a reason this hasn’t been implemented sooner: it’s an important feature nobody wants to make a mess of.
That is absolutely the wrong decision (and I feel strongly on this). With all due respect, you’re not a maintainer of either project, and if your PR were merged you wouldn’t feel in your skin the breakage it caused for users, having to close a barrage of issues and deal with every user, while at the same time trying to figure out how to fix things and having to drop everything to contain the situation. You’re suggesting every users gets bitten by this, complains, and then we tell them “oh, just pin”. Not only will they be annoyed, we’d be back at my descried issue, where now they have no easy way to go back to the previous install. So no, this is not solved by the manual work of pinning. Admittedly, this is likely not going to suddenly break and be a mess for all users at the same time but if it is an issue we detect now, it is one we should fix now. Why? Because if it isn’t done now, there’s a good change it’ll be half-assed for a long time and that left us in big trouble in the past. We’d really rather not have half-done stuff laying around, just piling up issues and continually telling users about workarounds, getting verbal abuse from some of them in the interim. |
|
So, OK, thats' the solution of lacking such a core feature several years after HBC releasing, and seems all upgrade-relative issues have been marked close in the HBC repo:) Feel free to close the PR or fork it, I've no time on continue maintaining it. Wish official HBC upgrade will be available before 2018. |
I (and everyone on this issue, I’d say) do very much appreciate you taking the time to work on this. However, you just made my point that this feature would be left half-baked as you would no longer be willing to follow through with it.
That kind of snark is unwarranted. Especially since no one was disrespectful to you in any way. And again, you just said you wouldn’t work anymore on this so you’re marking yourself as part of the problem. The irony is palpable. This reminds of the puppy analogy. I’m sorry you feel that way, but to me that even signals you might not even touch this anymore if this PR caused other breaking changes, and that’s not a really nice way to contribute. It’s particularly jarring to me since you just dismissed the whole contribution without giving anyone else the chance to chime in and possibly come up with a better solution that would require less work. Either way, I again thank you (with all sincerity) for contributing and working on this. |
|
I, personally, would like to continue this discussion and work. Where would be the best place to have the discussion about upgrade/outdated/pin/unpin? One thing we could consider is adding a new DSL entry for "paid_upgrade" or something...maybe it takes an array of versions that require paid upgrades. When you run In that case, If you make it harder to "auto-update" to paid upgrades, I don't think that a revert mechanism would be needed. Nor do I think that we would end up polluting the repo with additional versions, etc. (though version pollution is still a thing). Another idea which I just had is perhaps the "paid_upgrade" DSL contains some sort of value indicating at which commit that formula was updated. As an example, let's take "some-commercial-package" which currently has at version 4.2 (and there is a cask for it) and they just released a paid upgrade to 5.0. The value of paid_upgrade: { 5.0: "sha-sum-of-commit-of-5", 4.0: "sha-sum-of-commit-of-4" }That's just an initial shot at a syntax - and we would probably need to leverage some kind of git commit hook to insert the sha sum of the commit in the correct place... However, this would give "us" (developers of > brew cask outdated
calibre
> brew cask outdated --show-auto
calibre
sourcetree (auto)
> brew cask outdated --show-paid
calibre
some-commercial-package (paid - 5.0)
> brew cask outdated --show-all
calibre
sourcetree (auto)
some-commercial-package (paid - 5.0)That is, The user could then run: > brew cask upgrade
=== Upgrading calibre ===
...
Done!
> brew cask upgrade --auto
=== Upgrading sourcetree ===
...
Done!
> brew cask upgrade --paid some-commercial-package
=== Upgrading some-commercial-package ===
...
Done!I would avoid the whole "pin/unpin" thing...it doesn't really make much sense to me from a cask perspective - but if it would be helpful, it could be included. Basically, it would just take the cask out of the list that is shown when running And, if we really want to get fancy, we could provide a command for That last one is really just a "throw it out there" kind of thought. It probably would be way too fragile. In fact, I've not got my heart set on any of these proposals...I just thought I'd put them out there. To be honest, I've been just fine with my (dumb) scripts brewcask-outdated.rb and brewcask-upgrade.rb...and I've been using a brewcask-appcast.rb script for managing the automatically-updating ones as well. Well - that was a long post to basically say "I'm willing" to help out getting an official "outdated/upgrade" command set for HBC...and I'd love to participate in the conversation that needs to happen in order to get it implemented. |
That won’t work. A paid upgrade does not exist in a vacuum, it exists in relation to other versions so an array means nothing.
That’s an interesting notion, and one that would indeed (as you mention) remove the need for However, there’s a corner case that is yet to be addressed. Say we have a cask at
There was recently a discussion on why that is a bad idea. Especially this part:
That idea to me reads as “endless support requests”. It’s hard enough to keep up with casks as they are, let alone introducing complexity we do not control. |
|
All of your points make perfect sense. As I'm thinking about it more, it seems like if we were to (somehow) make automatic updates to paid versions more difficult and get rid of the It seems to me like anything more than supporting the "latest" version is beyond the scope of what homebrew and homebrew-cask are intended to do - as you mention, it is just "endless support requests". To say nothing of the fact that many of these companies that put out the software don't even support previous versions of their own software (you want support, you upgrade to the latest version). I guess what I'm saying is I was completely overthinking this - and perhaps if we were to provide a I'll keep thinking on it...but maybe it really is just a matter of adding a Then, Doing that, we wouldn't have to even worry about the "user is running 4.1, never upgraded to 4.2 or 5.0, and now we are at 5.1" case. If software offers "paid" upgrades, it is up to the user to determine whether or not to actually apply that update. There is never really a way that we'll ever be able to understand or map how the paid upgrade works...there are too many different variables. For example, a company can automatically allow your 4.2 license to work on 5.0 if you purchased it within 3 months of the 5.0 release date...we'll never be able to map all those possible scenarios. I would suggest keeping it simple...either software automatically updates or not (we already track that). Either they provide paid updates or not (we don't track that). That does, however, bring up another point...perhaps there should be a And along those same lines, there perhaps should be a It seems like there should be some kind of documentation around the requirements of an I do think that this would be a helpful feature (helpful enough that I have been maintaining my own |
That is indeed the case.
But this is an awful experience. Maybe you don’t want to pay to upgrade now. Making you remove the main cask (so it does not upgrade) and install (and perhaps specifically add) the old version in caskroom/versions just so you have it until you decide to pay for the upgrade (and go back to the main cask) is disrupting your workflow. It’s breaking what you have and then saying “now go fix it manually”. We’re not going to do that. It makes much more sense to either say “we’re not going to upgrade you until you give us a flag saying you really want to” or “if we just did an update you weren’t ready for, give this
Again, this can’t be done because a paid upgrade is not done in a vacuum. Not every upgrade is paid, and we don’t want to block on every minor one.
True, but that is clearly an exception. I those cases, the user will just “yes, force the upgrade” or “no, do not revert the upgrade”. We can continue to discuss here. After we get some kind of consensus, I’ll write a proposal (à lá Homebrew/homebrew-cask#13201). |
Yes - that is what I meant. I left off a "d) don't upgrade and just keep running the version you already are running" in my list. 😄
I would argue that we would want to block on every minor one. The way I would envision it working is for "paid" software, we don't auto-upgrade anyone ever - not even to minor updates. The I think that the interaction should be something like this (being super verbose here...maybe there is a better way to guide the user): > brew cask upgrade some-paid-application
==> Upgrading some-paid-application
Warning: some-paid-application provides paid upgrades.
The latest version is 5.1 (you have 4.2 installed). Please check with the developer to
determine if your license can be upgraded ('brew cask home'). You can then do one
of the following:
1) Update to the latest version: 'brew cask upgrade --force some-paid-application'
2) Ignore this update: 'brew cask upgrade --ignore some-paid-application'
3) Ignore all future updates: 'brew cask upgrade --ignore-all some-paid-application'
4) Replace your cask with one in caskroom/versions: 'brew cask replace some-paid-application4'
... etc ...Perhaps something like |
|
You know what would be nice is a Understandably, it would require more maintenance...but it still would be pretty cool 😄 |
|
I'll keep old internal politics out of my addition here, but I am utterly baffled why it was decided it was a good idea to merge #1808 before this PR really goes anywhere in terms of deciding whether it has a future or not. I've discussed some of this in the past at ridiculous length so it's not like this has never been flagged up, and I'm not going to paste an essay here because I don't think there's much to gain by doing so, but I think when you have Casks like Obviously this needs to be handled delicately but I think merging #1808 before this is resolved was reckless, and beyond that not entirely factually true given formulae can be used to create relocatable app bundles, either through simply installing |
A deprecation doesn't change anything except printing a message. We've been talking about
If you want to propose removing the Chromium cask for security reasons, that's another discussion. I'd argue that it's effectively the expectation on macOS for |
|
All that said: I do think there's value for someone to pick up and progress with this work although it may be worth someone like @vitorgalvao sketching out maybe in a |
I do really have to get on that, yes. I’ve been thinking more about it lately, and maybe this can work even without Reason being we have That being the case, removing |
👍 to reducing scope
👍 |
|
First draft of the outline, with the latest points of the discussion in mind: Homebrew/homebrew-cask#29301. |
|
Closing this in favour of that issue or a future PR. Thanks for the work anyway @palxex! |
brew testswith your changes locally?The long waited feature for brew cask to became a REAL package manager - at least for myself 😄
Currently using a naive method for version comparing - since I'm not familiar with existing homebrew development, I don't know whether homebrew already implement a more robust one. If so please mention me how to use it 😄