Changes to homebrew-cask installation behaviour #13201
Comments
|
Seems like a useful change, and might be timely as well - I plan to do a clean install with 10.11, so breaking changes are not a huge issue. So does the Would an example of a formula where |
Well, depending on how long the implementation (and release) takes.
For now, preference should be left with versioned urls. The overlap of apps that auto-update and apps that have unversioned urls isn’t clear (
This is incorrect. A cask having an unversioned url (i.e. it almost exclusively will use |
|
Is there a milestone, task list, thread, or wiki page where people can go check how much of this has been implemented and/or released? |
Not currently. Things should be released as issues as time goes on. It might actually take a few weeks for development of this to start, but this is the type of thing that should be announce early. |
|
👍 If apps come in a folder with a bunch of other things (readmes, licenses, plugin directories, etc.) will those be moved to Should If an application downloads the latest update when necessary, but does not install it for the user, should it be considered |
No. See point 4 of The end of linking, and the beginning of moving (technical) in the top post. Only what we already link will be moved, it’s one to one.
Than we use
Yes, so anyone installing it for the first time gets the latest version. Many (most?) of these have discoverable appcasts, though, which makes the job easier.
No. Only the ones that can do it seamlessly should, because otherwise we can still provide a better experience. |
(The following is my own preference.) I don't like folders in the Applications folder unless it really is to organize a bunch of apps (Microsoft Office). Suggestions for apps like Audacity and Eclipse that have a required folder structure:
Suggestions for apps with non-code supporting files:
|
|
I like those ideas, @szhu. However, I’ll also say “definitely not for now”, and the first paragraph of the top post explains why. Those could introduce issues we’re not foreseeing, and this change is in part meant to fix things, not introduce new possible points of failure. It doesn’t mean we can’t revisit those in the future, naturally, but for now the takeaway from this post should be emulate regular usage. Let’s nail that first, and only then see if being smart can pay off. |
|
Okay. I'm assuming that means the following:
|
Move it, using
Leave it in the caskroom. Both those points were addressed in the previous post. |
|
You reference |
|
Yes, it is changing that behavior. You will still be able to use |
|
Was there an open discussion of the pro's and con's of this somewhere that I've missed? |
It was all covered in the top post. @scribblemaniac’s explanation is correct. @tjnycum Yes, there were multiple, including #3083 and #3888. I have a slight feeling from your last comment and this one you might be under the impression this might be a matter of user preference and voting. It’s not. This is about fixing a broken model, and I’ve spent many months thinking about this solution and managing homebrew-cask always with that in mind, to understand how it’d affect it. Keeping the old system is unsustainable.
Every time there’s a new problem our workarounds fail to address we have to discuss how to implement a new one. Those are becoming harder and harder, and many of them are impossible to solve without breaking experience. All of them are solved immediately by emulating regular usage. As mentioned in the top paragraph of the top post, being smart failed, and as mentioned in a previous post, let’s first get things to work, and think about being smart later. |
|
👍 i want this for years |
|
After just quickly scanning 👍 on the This big changes can be annoying in the short term but it's good to figure these things out while the project is still relatively new than wait 10 years and have to deal with everything breaking |
|
I'm interested in how this is going to work in a situation where a user has already installed an app from the Mac App Store. Will an overwrite prompt be given? |
|
@kevinSuttle I believe that was addressed in the previous comments. Since the app was not installed beforehand, and the file exists, a warning/error will be given and no overwriting will take place. |
|
Actually, I just tested out Skitch. There was no prompt at all.
Brewfile |
|
Was able to reproduce with several App Store/free apps. Evernote |
|
@kevinSuttle There is no prompt. This is what happens if you already have an app installed: No failure is reported because nothing failed. The cask was downloaded, unpacked, and staged. We won't remove an existing non-cask installation. |
|
I'm telling you it's happening on my system. Clean install of El Capitan. I'm running |
|
Have you double-checked your |
|
In any case, what you are reporting would be a bug with the existing behavior of |
|
@jawshooah Help my understand why In any event, what's the recommended way to batch install multiple casks? |
|
@kevinSuttle See https://github.com/Homebrew/homebrew-bundle for issues with homebrew-bundle |
|
@kevinSuttle We are not Homebrew. Homebrew and Homebrew-cask are maintained by completely separate teams. Therefore, If you want to install multiple casks, a simple shell script would suffice: brew cask install \
skitch \
evernote \
alfred \
...Or perhaps: brew cask install skitch
brew cask install evernote
brew cask install alfred
...Or even: casks=(
skitch
evernote
alfred
...
)
for cask in "${casks[@]}"; do
brew cask install "$cask"
done |
|
Ok, that makes sense. Thanks @jawshooah. |
|
Why is it that after I |
|
@satomusic Oh launchpad don't mind whether it is a symlink or a directory. |
|
Then can I take that directory from launchpad and apply that to my |
|
@satomusic Your problem has nothing to do with this issue. Lets please stay on-topic, it is big enough as it is. Either way, it’ll be irrelevant once this is up, so we won’t work on it. Furthermore, your last post is an OS X question, not a homebrew-cask question, so you should resort to a website with that specialty, like Ask Different from Stack Exchange. |
|
@vitorgalvao I recommend you post one more comment that sort of acts as an FAQ and then lock this thread. I think the FAQ should include answers to the following questions (my best-guess answers are in parens):
|
|
@szhu I like that, thank you. Nothing further to add to your FAQ, so we can leave it as is. I didn’t want to close this at the start because I wanted people to find holes in it, but it seems like the idea as it stands is pretty solid and agreed upon, so yes, lets stop diverging further since comments have been becoming less relevant. |
Zulu is a supported release of OpenJDK published by Azul systems.
|
The first and most important part of this change is now very close to being implemented. If you’re interested in helping test it, head over to #13966 and follow the instructions at the bottom. |
|
Getting really close, now, so if you had some things you wanted to do that are dependent on this change, now is the time. |
|
And merged. There are still a few things that need to be done in order to close this issue, but the biggest user-facing change is now present. |
|
@vitorgalvao, what exactly still needs to happen for this to be closed? The only thing I'm seeing that is not yet implemented is Why would you be able to override a required location? That would mean the location isn't actually required. |
|
@reitermarkus As for |
|
I suggested We should absolutely print a warning when the user overrides |
|
@vitorgalvao, I think we can close this in favour of #12858. |
|
@reitermarkus Agreed. At this point other issues should take care of whatever is missing here. |
Changes to homebrew-cask installation behaviour
Depending on how long you’ve been following the development of homebrew-cask (henceforth HBC), you might’ve come across this great rant1. It was the turning point in making the
linkstanza (precursor toapp) a requirement to every cask. Prior to that, HBC tried hard to be smart about what to link, but we eventually concluded being smart doesn’t work — there are too many edge cases.The end of linking, and the beginning of moving (reasoning)
We reached another such point with linking. What works for CLI apps does not work for GUI apps, and by sticking close to the homebrew model we’re bending apps to do what they’re not expecting, and only suffering from it. Issues we cannot fix continue to pop up, and copy as merely a preference or something to be done occasionally can’t solve them. We cannot, in addition to the inconsistency with
pkgs being installed instead of linked, add yet one extra inconsistency where evenapps won’t have a predictable behaviour. To put it bluntly, linking sucks for GUI apps. It doesn’t work and will never not be broken, as we can’t control what other developers do.Linking isn’t even needed, if you think about it. What separation of concerns are we worried about? CLI tools should have the separation homebrew provides because some of their apps (like newer versions of OS-level tools) provide critical features that could break the entire system if overridden. That is not the case at all with GUI apps; the only apps we have that could break the system on install (
pkgs) are already given free range. If you use HBC, there’s not even any reason to install a GUI app any other way, so why would that separation matter?GUI apps aren’t the only suffering from the current behaviour, even. Other artifacts suffer from similar issues and some even required the introduction of a different kind of linking.
In addition, while having different versions of the same CLI app is many times desirable, that is a far from the norm with GUI apps. Having an
upgradethat works on every app, even ones that auto-update, also becomes nonsensical.We should emulate regular usage (i.e. what people do without HBC), instead of trying to perpetuate a new paradigm that is basically contradicting expectations. This, however, does not mean losing customisation options when it makes sense (like
--appdir).Every workaround we build is forcing apps to fit our model, and our model is bad. We’re building workaround on top of workaround, adding more code and work for something that will never work correctly.
From The Cathedral and the Bazaar: “you often don't really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at least once”.
As with other changes in the past, we now understand this problem a bit better and will adjust our solution accordingly.
The end of linking, and the beginning of moving (technical)
First steps towards new behaviour:
binarywill move its target to the appropriate location, instead of being sym/hardlinked.apps will be moved to/Applicationsby default.:targetwill continue to work, but rename the artifact itself instead of a link./opt/homebrew-cask/Caskroom/by default) still needs to exist.Explanations:
binaryis linked from inside an app bundle and cannot simply be moved/copied from there and continue to work. In these cases, symlinking is the recommended (by the developer) course of action anyway, so we stay in line with the idea of emulating regular usage. It also makes it work similarly to other CLI tools, like installs from homebrew.binary, when they’re standalone.pkgs.New stanzas/keys/flags to enhance these changes
auto_updates. Similarly tostage_only, it should be used when a value oftrueis needed. It means “the artifact this cask uses auto-updates, so even if the cask file updates, leave this alone when upgrading others”. This does not meanupgradein general is no longer a desirable feature — it is, but for casks who do not do it themselves.:required_location. Example:app 'FontForge.app', :required_location => '/Applications'. It means the artifact needs to be in a certain location to function correctly and as such will be moved there even if you have a different default location.--force-appdir. Takes no arguments and forcibly overridesrequired_location.Pseudo-code for
:required_location, considering anapp:Doesn’t this mean a bunch of stuff might break?
In the short term, yes, it does, but it is the right decision. We understand we have a bunch of users that are using homebrew-cask daily, and ideally we could try to make this a smooth transition like in the past. However, we’re admittedly pre-alpha and setting transition strategies is an inglorious job (everything will be discarded in the end, after all) that puts on hold even the smallest of changes indefinitely. It is incredibly time consuming, has variable results (we still get a bunch of issues pertaining to it), and (above all) kills momentum. Furthermore, this is a big change and there’s really no good way to make this seamlessly.
In the end, we want to continue to move forward and improve HBC. Being afraid of changes in a pre-alpha would mean stagnation.
Are there any other big changes planned?
There are ideas, yes, but no exact plans yet. Those ideas still need to be discussed and most are concerned with the creation and maintenance of casks, not the usage of HBC.
1 If you haven’t, I highly recommend it as piece of HBC’s history.
The text was updated successfully, but these errors were encountered: