What is the syntax for brew link @-versioned formulae?

[MadalinSava]

I can't find this anywhere. Basically I was doing brew switch and after a homebrew update it says
"Error: Calling brew switch is disabled! Use brew link @-versioned formulae instead."

I tried brew link [email protected] and lots of other variations, but nothing works.
"Error: No such keg: /usr/local/Cellar/[email protected]"

How should this work? Everything in my environment is fine, there shouldn't be any issues related to that.

[gromgit]

brew link doesn't support arbitrary versions. The "@-versioned formulae" mentioned in the first error are actually separate formulae that are created according to fairly strict rules: https://docs.brew.sh/Versions.

The linking of arbitrary versions of the same formula died along with brew switch.

[carlocab]

fatal: repository 'https://github.com/MadalinSava/homebrew-<formula>/' not found.

That's weird; I didn't think extract looked for a GitHub repo by default. Did you do brew tap-new MadalinSava/<formula/tap name> before extract?

[MadalinSava]

@carlocab at first no, I just tried it to see what it wants to do, but I did tap-new just before and then again extract and install, and it worked.

Now I'm trying to figure out if we'd need to have a remote repo set up for this but it doesn't seem to be worth it because we can't just have a .rb file in there and just download and install. So even though it takes a lot longer to do the clone and make through extract and install, it should be a one time thing (per version upgrade, ofc) and it's the safest and future-proof way.

Thank you! :)

[EricSocs]

Here's a less fragile way of doing it:

brew tap-new MadalinSava/<tap name>
brew extract --version=<version> terraform MadalinSava/<tap name>
brew install terraform@<version>

brew tap-new MadalinSava/<tap name> creates a git repository at $(brew --repo MadalinSava/<tap name>) which will look like an empty version of homebrew-core. brew extract adds the formula you want (with the given version) to your tap.

If the brew install step gives you problems, you can try

brew install MadalinSava/<tap name>/terraform@<version>

I've been having to switch between icu4c 64.2 & 67.1. Tried this solution but it didn't work for me. I'm scoping these into LegacyDependencies for clarity:

brew tap-new LegacyDependencies/icu4c
brew extract --version=64.2 icu4c LegacyDependencies/icu4c
brew install [email protected]

Link attempt gives me:

➜  Formula git:(icu4c-64.2) brew link [email protected]
Warning: Refusing to link macOS provided/shadowed software: [email protected]
If you need to have [email protected] first in your PATH run:
  echo 'export PATH="/usr/local/opt/[email protected]/bin:$PATH"' >> ~/.zshrc
  echo 'export PATH="/usr/local/opt/[email protected]/sbin:$PATH"' >> ~/.zshrc

For compilers to find [email protected] you may need to set:
  export LDFLAGS="-L/usr/local/opt/[email protected]/lib"
  export CPPFLAGS="-I/usr/local/opt/[email protected]/include"

For pkg-config to find [email protected] you may need to set:
  export PKG_CONFIG_PATH="/usr/local/opt/[email protected]/lib/pkgconfig"

Any pointers appreciated.

[carlocab]

You probably have keg_only in your formula file for [email protected]. You can either remove that (not recommended) or use the environment variables suggested by the error message you just shared.

[EricSocs]

I had to remove the keg_only part of the formula. Environment variables were somehow ineffective.

Find out where the formula file's been extracted:

brew extract --force --version=64.2 icu4c LegacyDependencies/icu4c
==> Searching repository history
==> Writing formula for icu4c from revision 896d101 to:
/usr/local/Homebrew/Library/Taps/legacydependencies/homebrew-icu4c/Formula/[email protected]

Edit the formula file to remove the keg_only part.

vi /usr/local/Homebrew/Library/Taps/legacydependencies/homebrew-icu4c/Formula/[email protected]

Reinstall:

brew reinstall [email protected]

This should work for me until I get around to setting up this old environment in Docker, which I've delayed for too long!

Thank you @carlocab!

[twwwt]

What was the motivation to disable the switch command? What should we use instead for a formula that is not versioned according to Homebrew's definition of versioned? For instance, I've used this for gradle for a couple of years. It was a breeze to use - as quick as possible. I never had problems with the command. Is the solution proposed by @carlocab the only way to work around it? I don't consider this a solution. It's not taking Homebrew forward - it's going backward. I think either the switch command should be re-introduced (possibly warning about its problems), or an alternative should be implemented.

[he-sk]

I'm still interested to learn about the motivation of having switch disabled. I found out from the changelog that it was deprecated in 2.6.0 but the linked pull request doesn't provide additional information.

[SMillerDev]

Using brew switch allowed users to switch to unmaintained and possibly broken builds of software Homebrew software and tricking homebrew into thinking that was the latest version. brew link makes sure that the software actually exists and is maintained and is therefore a better experience for most users, and needs less support from the maintainers.

[jguenther]

@SMillerDev could you explain this bit please?

Using brew switch allowed users to switch to unmaintained and possibly broken builds of software Homebrew software and tricking homebrew into thinking that was the latest version

was this something other than people submitting bug reports without first doing a brew upgrade?

losing brew switch makes every upgrade extremely risky, unless I'm missing some way to "undo" an upgrade.

[he-sk]

losing brew switch makes every upgrade extremely risky, unless I'm missing some way to "undo" an upgrade.

I agree. The ability of Homebrew to keep the previously installed version and downgrade to it quickly is an extremely useful feature that I've used quite often in the past.

[SMillerDev]

was this something other than people submitting bug reports without first doing a brew upgrade?

It was people doing an upgrade, switching back to openssl 1.0 for example, and complaining that everything the depends on openssl being as homebrew ships it is broken.

losing brew switch makes every upgrade extremely risky, unless I'm missing some way to "undo" an upgrade.

Every package update tests all its dependencies in CI so it rarely happens that a brew upgrade breaks a part of brew.
If you need specific versions of software for development, using a container, virtual machine or something like rbenv is probably a better solution than mixing homebrew versions, since that was never an intended use case.

[jguenther]

example of an issue caused by this today for me:

Today I upgraded a package, which apparently pulled in ruby as a dependency of one of its dependencies. so ruby was upgraded too even though I didn't request it (ruby was upgraded from 2.7.2 to 3.0.0_1)

now everything related to ruby is broken on my system, which I eventually figured out was from that upgrade this morning, and I had to find this thread to figure out why brew install [email protected] didn't work as the error message seemed to suggest.

I tried deleting 3.0.0_1 from /usr/local/Cellar/ruby/, so I could brew unlink ruby/brew link ruby to switch back to the the old working version of ruby, but now brew link ruby and brew unlink ruby both give me this error for the unrelated brew uninstall command:

$ brew link ruby
Error: ruby has multiple installed versions
Run `brew uninstall --force ruby` to remove all versions.
$ brew unlink ruby
Error: ruby has multiple installed versions
Run `brew uninstall --force ruby` to remove all versions.

how can I recover from this situation, other than manually fixing every mention of ruby on my system/config to refer to [email protected] instead of ruby?

is it no longer possible to ever go back to an older version after an upgrade with homebrew?

is this a separate bug that I should report, or is the intended behaviour?

[SMillerDev]

This is intended behavior. Homebrew will always provide you with the latest versions of software. If you need a specific ruby version, rbenv is my recommendation.

[Ignalion]

This is intended behavior. Homebrew will always provide you with the latest versions of software. If you need a specific ruby version, rbenv is my recommendation.

It shouldn't be the way of things. Though point about rbenv (or something like anaconda in case of Python) is valid however there are a lot of software that don't have each own packet manager and still the newest version brakes some support for a lot of features.

[danielnachun]

I use Homebrew on 3 Linux systems and my MacBook and these are a few more suggestions I can make to help avoid some of these issues in the future:

1. Don't install anything into the cellar of a package or modify the files in there. Everything in the cellar gets deleted when a package is upgraded. The only package I've used that required intervention to stop something from being installed into the cellar is perl, and when you install it, it warns you about this and gives you specific instructions about how to fix it.

2. You can always check what will be upgraded by brew upgrade first by running brew update and then brew outdated (or brew update && brew outdated if you want do it in one line). If you see a package in the list whose upgrade you think will cause issues, you can use brew pin to temporarily hold it back from being upgraded while you figure out how to deal with the upgrade. Do note that doing so means you can't upgrade any package that depends on the pinned package, so you should just use this as a stopgap measure until you've figured how to manage the upgrade.

3. Some packages create a link in $HOMEBREW_PREFIX/opt/ which is versioned even with the current version (for example, the python package creates a link at $HOMEBREW_PREFIX/opt/[email protected]/). In those cases, you could point any configurations to that path instead of $HOMEBREW_PREFIX, and whenever python gets upgraded to the next version, a versioned formula will probably created for [email protected] which you could install and your configurations would still work.

And to reiterate what has already been said here already, the goal of Homebrew is to provide you with the latest software, not to maintain strictly versioned environments. Many other tools exist to allow you to install versioned software - containers, Anaconda, Spack, python virtualenvs, rbenv, etc. All of these can be used side-by-side with Homebrew (in some cases it takes a bit of work to make them get along).

I have personally found that software or configuration setups which have difficulty keeping up with dependency changes to be brittle and often not designed with the future in mind. My philosophy on this is best summarized by a funny quote from the former sysadmin of one of the clusters I use:

It's important to note that "backwards compatibility" and "software reproduciblity" are lies and misdirection and not based on reality. Time will march on and leave everything (including us) behind eventually, if a project has a hard dependency on a specific version of anything and no clear set end date for that dependency, then it has a critical bug.

[Ignalion]

Well, as the thing called 'reality' always happens I need to downgrade some versions. As far as I understand if there is only one formulae for software, I can't install any other one? Can I then downgrade homebrew to the version that allows brew switch? Which version would it be then?

[carlocab]

You can try what I describe in this comment instead: #339 (reply in thread)

[vikas027]

Sorry, but that's an ugly of way of doing it. I wish this was deprecated a bit more gracefully.

One (out of many) of my use case - I am a contractor and work across multiple organizations and customers. I heavily use terraform for automation which is pinned to different versions. Imagine the chaos doing that multiple times in a day.

[carlodef]

A possible fix is to downgrade brew to 2.6.2

cd /usr/local/Homebrew
git checkout 2.6.2

With that you should get brew switch back working. You may want to set the env var HOMEBREW_NO_AUTO_UPDATE to 1 in order to avoid brew updating itself at every run.

[mbarriault]

I will also contest the removal of brew switch, as I need to use Homebrew's versioning to manually install (as in built from source with --prefix=/usr/local/Cellar/package/version) multiple versions of a package (often packages, versions, and build options not found in Homebrew's default formulae) and switch between them without having to update paths constantly. Indeed the removal of this feature has completely broken my workflow and largely makes Homebrew, previously an essential tool, useless for my job.

[he-sk]

I also used this workflow for a number of manually installed software, including Homebrew packages that for some reason are broken on my system (e.g., ledger). It might not be intended by Homebrew but it was super-easy and incredibly useful. I'm not aware of an alternative that offers such a simple workflow to manually install and uninstall software. Creating a complete formula is much more overhead.

[danielricecodes]

I think the maintainers of homebrew forgot that consultants and agencies use homebrew and systems like it to manage multiple projects, on multiple versions of multiple dependencies. Removing switch is a huge setback for my line of work. I am now looking for a better package manager....

[SMillerDev]

I work for an agency using Homebrew with multiple projects and multiple versions and multiple dependencies. It works like a charm, Homebrew maintains the latest versions and I extract the versions that I will need later or I use a docker container if I need versions to be truly stable/immutable.

[spikegrobstein]

docker can be a non-starter if you're doing a lot of filesystem i/o or are using any packages that use macOS-specific features (like keychain, opening browser windows, applescript, etc). not to mention docker for mac's stability issues.

[SMillerDev]

Yeah, that's usually where I extract versions. I'm not saying it'll work for everyone. But I am disputing that this makes life impossible for agencies.

[Syphixs]

This change forces me to use homebrew 2.6.2 (with switch command available) as long as a new package manager arrives. Creating a new formula for every old version which does not exist but is needed for compiling is just insane.

[SMillerDev]

It seems you ran into the issue that prompted people to start using docker/virtual environments if they need specific versions.

[spikegrobstein]

this is causing my team some grief in my development cycle as we use brew switch heavily to test code in the live homebrew install on our machines. there isn't any other way to tell homebrew to link everything up from a working development checkout without committing/pushing first.

Using the --HEAD option isn't always viable, especially when starting new packages that haven't yet had a repository created and it also causes homebrew to tie the install to a specific branch.

it's looking like we're going to have to build our own brew switch tool to reintroduce this functionality unless there's another workaround available.

[pburkholder]

The folks at Cloud Foundry have https://github.com/cloudfoundry/cli/wiki/Version-Switching-Guide which includes this guide for brew versions for their CLI:

---

Switching CLI versions Using Brew

Assuming you've installed both the v6 and v7 CLIs as follows:

    brew install cf-cli@7
    brew install cf-cli@6

Switch from v6 to v7:

    brew unlink cf-cli@6 && brew unlink cf-cli@7 && brew link cf-cli@7 && cf version

Switch from v7 to v6:

    brew unlink cf-cli@7 && brew unlink cf-cli@6 && brew link cf-cli@6 && cf version

Does that help?

[rfay]

No, it doesn't help, because it requires that the separate version formulas already exist, and what we all want to do is just swap versions, for testing or whatever. In the same formula.

[pburkholder]

Right, it'll help @vikas027 for, e.g., terraform, but not the broader majority of uses where I need to pre-/post-update impacts.

[spikegrobstein]

I figured out how to re-implement the old brew switch behaviour. Luckily it's not terribly involved.

#! /usr/bin/env bash

set -euo pipefail

pkg=$1
version=$2

brew unlink "$pkg"
(
  pushd "$(brew --prefix)/opt"
  rm -f "$pkg"
  ln -s "../Cellar/$pkg/$version" "$pkg"
)
brew link "$pkg"

I hope this helps someone who is affected by this change.

EDIT: put this script in your PATH and name it brew-switch and you'll have a good time.

[laggardkernel]

All changes of switch.rb found by git log

# https://docs.github.com/en/github/writing-on-github/autolinked-references-and-urls
# If you wanna make the following links clickable, paste them in a TextField and preview them.
# But DON'T submit the pasted content.

Homebrew/brew@d1f3e39 Update commands to generate usage banner
Homebrew/brew@3323724 cmd: indicate multiple named args in usage banner
Homebrew/brew@74fb058 More deprecations for Homebrew 2.7.0.
Homebrew/brew@5be4c9b Upgrade `typed` sigils.
Homebrew/brew@d496f5c Deprecations for Homebrew 2.6.0

Get the source of switch.rb from the last commit above, and apply changes if needed in each commit. Here's the final switch.rb file I got.

Then create a custom tap and put the file as cmd/switch.rb under the tap's root folder. Use the tap. It will get back the old goodie brew switch.

I don't recommend you use my custom tap directly.