-
-
Notifications
You must be signed in to change notification settings - Fork 11.3k
Changed brew linkapps to use /Applications (not ~/Applications) #17643
Conversation
…the global) /usr/local directory
I don't like this |
Other maintainers: override me, or I'm rejecting this. |
@adamv I'm not sure I understand what it's doing and why? Never used |
|
Why did you not use that in the first place? Permissions/cleanliness? |
Homebrew policy is to not mess with system folders, right? The only things I put in /Applications are Apple apps (Aperture) and things that insist on pkg-installing there (like Fusion). |
Considering I don't use this tool I think it's basically down to your preference. I certainly think just changing the default will be confusing regardless of the merits. |
I would accept a pull request that added a |
I personally would prefer /Applications. In addition to a run time flag, I would find a permanent config flag desirable. |
See 2569641 |
I've gotta throw in a +1 here. I understand the “don't modify the system” argument, which is great and all … but, if you think about it, the real spirit of that mandate (correct me if I'm wrong, @mxcl) can be better broken down into the following:
Now, sure, Breaking it down using those two points above … while placing applications in the user's home-folder is certainly non-obtrusive (point 1), it's definitely later surprising to the user. (Who, other than @adamv, actually uses My personal opinion: I'd like to see My suggestion: Whether or not my own desire is fulfilled here, I'd request that this issue be re-opened for discussion, and that some more users be polled in some fashion. I very very much doubt that very many would want to see |
+1 for @ELLIOTTCABLE's solution. The only time I ever interact with ~/Applications is when Steam puts symlinks to games in it without asking. Few OS X users really expect /Applications to be left alone, and putting things elsewhere probably does more damage than good, workflow-wise. A flag + per-user configuration option would be a great way to cater to both. |
Take it to the mailing list; this is a 5 month old closed issue. |
I think it should be Edit: Honestly, with hindsight, I'd make it so you didn't even need a further command to have Further: with true hindsight I would have prohibited |
I'd merge this but I don't know enough about the command, I don't use it. I am not willing to be the one who breaks things for other people. |
This was later resolved in this PR: So I'd strongly recommend not merging this earlier version. |
I'd say that it wasn't resolved, nor is it relevant; that's a flag to ask for one or the other, whereas I am here arguing the default functionality, and whether it's user-friendly in it's current design. ⁓ ELLIOTTCABLE — fly safe. On Wed, Sep 4, 2013 at 6:20 PM, Iain Beeston [email protected]
|
I agree with @ELLIOTTCABLE that a user conf is still more desirable than just a flag, and And for @mxcl, I would point out that programs closely tied to the cli are still in the community's interest (macvim, wireshark, gtk, etc). Do we have frivolous apps I haven't noticed? |
Maiiiiiiiiling list. Guys this issue is closed which means it is a bad place to converse. Linkapps is a "unsupported" contrib command, so discuss on the mailing list or make a new pull request. Not here. Thank you. |
+1 on /Applications being the default Sidenote, if you want things on the mailing list, it needs to be 1) easier to find and 2) easier to work with. This issue comes up higher in google results. In fact search for "homebrew mailing list" doesnt even give good results for it. Once I found it, I found its unusable: no search, sorting or filtering. |
@eddiemonge I mostly don't want things to be in very old closed threads, I tend to "mute thread" when old bugs get new comments. |
very old closed threads are often good places to put things. it helps explain the reasoning behind something. however, having a way to have those reasons while keeping relevant information updated would be best. |
@eddiemonge I guess what Adam is politely saying is that if you want maintainers to actually listen to you, don't do it on closed threads. |
This is a solution to #8699 based on the suggestion by @thecontrarian. Nobody else has actually made a pull request to change this, so I thought I'd give it a go.