-
-
Notifications
You must be signed in to change notification settings - Fork 9.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to link/unlink a single file from a formula #19024
Comments
Yeh, it will.
Reordering your PATH. Can I ask why you don't want to do that? |
More of a personal reason than anything really, /usr/local/bin already gets added to my path (I think it's because of /etc/paths, as it's not something I added specifically, but I'm not sure what the reprecussions of me removing it would be as, like I said, it's not something I added) and I don't want to overclutter my path by including /usr/local/bin twice if unneccessary, more than a cosmetic reason than anything I guess as it's already pretty cluttered as-is... Hope this makes some sense! Besides that, though, I do think there are other use cases for this besides just executable paths; for instance, it could be useful for conflict resolution between formulae where you want a binary from one formula but also don't want to unlink the whole other formula just to get it. |
Thanks! Can you be more specific about the specific executable(s) in the specific formula(e) you want to be linked/not? |
"compare" from imagemagick and "nova" from open-simh are the commands I've unlinked. |
@iblowmymind What are they clashing with? Personal scripts? Other packages in Homebrew? |
Commands that other programs install- Araxis Merge installs a "compare" command, and Panic Nova has its "nova" command. |
Do you install these with Homebrew Cask or without? Where are these files installed? |
Without, the apps are standalone. The nova command installs to /usr/local/bin while Araxis Merge requires you to manually add a folder inside the application bundle to your path. |
I've run into this issue(?) in the past too and have had to unlink specific files to avoid clashes. A feature like this would certainly be useful to me, too. I've had various conflicts like this over the years, but the one I can think of off the top of my head:
I want to use other binaries provided by |
in case like this: could you not just put it in front of Homebrew in your PATH?
The likely solution to cases like this is we make one of these formulae keg-only (or make conflicts link-aware). |
Verification
brew install wget
. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.Provide a detailed description of the proposed feature
The ability to unlink a single file/command instead of a whole formula and have this be preserved and respected across formula updates, so it doesn't get linked again. The command could be something like: "brew unlink --file (formula name)/path/to/file". (Open to suggestions!) The same can apply to brew link as well to link an unlinked single file back. (Unlinked files could be listed with "brew unlink --file --list", maybe?)
What is the motivation for the feature?
I have a command line utility symlinked from an application that clashes with a legacy imagemagick command (convert, more specifically). I don't really want to reorder my PATH and put this directory above brew, nor do I want to unlink the whole imagemagick formula to get this command running. This gave me the idea for granular file link/unlink and I would really appreciate it if this feature was available.
How will the feature be relevant to at least 90% of Homebrew users?
I'm sure granular control over modifying paths beyond simply link/unlink whole formulas created by Homebrew will be useful to a great portion of its users, as putting a path entry way above Homebrew may not be viable in some cases.
What alternatives to the feature have been considered?
I've resorted to deleting the offending brew symlink by hand for now, however I don't know if it will be replaced when the formula gets updated (it probably will). Besides that, I don't know of any real alternatives for this behaviour.
The text was updated successfully, but these errors were encountered: