As discussed in #1220, cleaning up after stopping Homebrew services that
run as root is probably the best solution for now.
What's changed:
- Stopping any Homebrew service now restores the appropriate permissions
for the Homebrew directories
- Stopping nginx now also happens via $this->brew
(to avoid code duplication)
The tests were updated to reflect this change.
Before the change, when running `valet use` the code intended to stop currently running PHP services. But the `getRunningServices` method only returned non-root running services. As PHP services started by Valet are run using `sudo` (so running as root), they were not returned and subsequently not stopped.
This change is intended to fix the above and stop PHP services that are started by Valet on a PHP version switch.
This is intended to assist with avoiding having competing non-root instances of valet dependency services running due to userland use of brew CLI commands.
Now, when running `valet stop` or `valet restart` it will (silently) attempt to stop the non-root instance (ignoring any errors thrown), before stopping (and/or starting) the sudo/root instance which is normally used.
(Though obvious, I'll point out that this only applies to services Valet manages.)
Fixes#1057
- properly detects if the requested version is already installed, and skips re-installing/re-starting/re-configuring
- allows --force to re-configure anyway
- smarter treatment of 'php' when it's aliased to another specific installed version
Fixes#756
Previously if `php` was installed as just `php` (the default Homebrew alias), Valet would not detect *which* PHP version was actually installed, and therefore `valet use` might do incorrect or unnecessary installations/links/etc.
NOTE: This does NOT "convert" existing `php` alias to a numbered version. It merely accepts it as-is, but notes its version in an attempt to avoid extra installations.
*NOTE: Specifally tested with PHP 7.4 and 7.3. No promises about old 5.6, etc aliases.*
`valet uninstall` only displays information about how to manually uninstall and clean up after Valet.
This PR adds a `--force` parameter, which will forcefully remove Valet and the Homebrew services it installs, as well as clean up the config files and log files.
But for a few post-uninstall composer dependencies, cleanup is very thorough.
This brings idempotency to both `valet install` and `valet uninstall --force`
(There may still be edge cases where other Homebrew or composer packages might create interference with install/uninstall, but this makes things much easier to self-troubleshoot.)
If you've previously run `valet trust` to allow valet to run without specifying `sudo` repeatedly or entering your password with various valet commands, recent updates to MacOS may give you a `sudo: sorry, you are not allowed to preserve the environment` response when trying to run those `valet` commands.
The fix is in updating the sudoers entry that `valet trust` creates.
This PR tells valet how to update the sudoers entry so that this message doesn't continue.
YOU WILL NEED TO RE-RUN `valet trust` IF YOU HAD PREVIOUSLY RUN IT, after installing this update, in order for this code change to have any effect.
(Technical explanation: the sudoers protections have become stricter, so we have to be more explicit that we do indeed want environment variables to flow through to the sudo user's environment when using valet via sudoers entries.)
Last year's Homebrew's PHP packaging changes altered their version numbering strategy.
Now that their changes appear to have stabilized, Valet also needs some updates to match.
The `linkedPhp()` function was parsing the symlinked directory name for where the php binaries are stored, but that numbering strategy has morphed over time.
This PR changes the logic to accommodate the most common directory naming strategies I can find, including those of older installs.
I've included some examples of these names in code comments for future reference since finding a variety of them can be complicated.
