This variable was getting filtered out before so it wasn't possible
for us to use it as the default for HOMEBREW_DEFAULT_CACHE
and HOMEBREW_DEFAULT_LOGS.
- split jobs into build/test/deploy
- test package on both macOS Intel and Apple Silicon
- cleanup some argument handling
- use `HOMEBREW_MACOS_OLDEST_SUPPORTED` naming to be consistent with
`brew.sh`
- note in `brew.sh` that `Distribution.xml` also needs updated (and do
so)
- various other little bits of style cleanup
We have no commands with Sorbet disabled and have had Sorbet enabled
for developers for a decent amount of time. As a result, we can enable
it for everyone who has run a developer command.
This also allows a bunch of `raise TypeError`s to be removed in favour
of relying on Sorbet here instead.
My understanding is that now https://github.com/Homebrew/brew/pull/15778
has been merged this should now work fine on both older macOS versions
and non-default prefixes so let's try this again.
- warn if running `brew postinstall` explicitly and there's no
`post_install` defined in the formula
- add a `post_install` alias for `brew postinstall` to make life
easier for those jumping between `postinstall` and `post_install` in
e.g. Homebrew development
- refactor `post_install` formula path logic into a new method for
improved readability
- handle the JSON API `post_install` formula path case
When we're automatically setting `HOMEBREW_NO_INSTALL_FROM_API`
when on an old macOS version or with a non-default prefix (e.g. cases
where you're going to be mostly building from source).
My initial plan was to set
`HOMEBREW_AUTOMATICALLY_SET_NO_INSTALL_FROM_API` in these cases but
it's used differently enough it made sense to add another internal
variable instead: `HOMEBREW_INSTALL_FROM_API_UNSUPPORTED`.
At the moment this is only used to avoid printing the "You have set
`HOMEBREW_NO_INSTALL_FROM_API`" message inside `brew update` but may
make sense to use in other places over time.
Ideally, we'll get rid of these automatic sets of
`HOMEBREW_NO_INSTALL_FROM_API` and perhaps even the variable entirely.
My understanding from conversations with Bo98 is that this should now
work fine on both older macOS versions and non-default prefixes.
Similarly, it's super confusing when this is set automatically and you
can't figure out why...
Correct `HOMEBREW_PREFIX`, and its only dependent up to that point, `HOMEBREW_REPOSITORY`, if the defaults contain symlinks. For example:
```console
$ realpath /home/linuxbrew/.linuxbrew
/var/home/linuxbrew/.linuxbrew
$ ls -ld /home
lrwxrwxrwx. 4 root root 8 Jun 29 22:29 /home -> var/home
```
I was hoping to correct `HOMEBREW_PREFIX` from the start (in `bin/brew`), but the default prefixes are in `brew.sh`. See #15656 for a discussion on this middleground solution.
Co-Authored-By: rohanssrao <17805516+rohanssrao@users.noreply.github.com>
Co-Authored-By: Bo Anderson <mail@boanderson.me>
These were introduced by typos and an incorrect assumption on the last
update of #15358. The last commit had been tested with a parameter, but
had not been re-tested *without* parameter.
Apologies for the error.
We need to exclude any command that might read `lsyncd` on Linux while
simulating macOS. This seems like all of them.
This reverts commit bcf94f6e27d26a6844ee1fa7af73333321015987.
Resolves#15358
With this change, `brew shellenv` will accept a shell name parameter to
override its default output (based on `/bin/ps`) for advanced use cases
such as with dotfile templating and caching with
[twpayne/chezmoi](https://github.com/twpayne/chezmoi/discussions/2971).
When running under `fish`, this is the output:
```console
$ brew shellenv pwsh
[System.Environment]::SetEnvironmentVariable('HOMEBREW_PREFIX','/opt/homebrew',[System.EnvironmentVariableTarget]::Process)
[System.Environment]::SetEnvironmentVariable('HOMEBREW_CELLAR','/opt/homebrew/Cellar',[System.EnvironmentVariableTarget]::Process)
[System.Environment]::SetEnvironmentVariable('HOMEBREW_REPOSITORY','/opt/homebrew',[System.EnvironmentVariableTarget]::Process)
[System.Environment]::SetEnvironmentVariable('PATH',$('/opt/homebrew/bin:/opt/homebrew/sbin:'+$ENV:PATH),[System.EnvironmentVariableTarget]::Process)
[System.Environment]::SetEnvironmentVariable('MANPATH',$('/opt/homebrew/share/man'+$(if(${ENV:MANPATH}){':'+${ENV:MANPATH}})+':'),[System.EnvironmentVariableTarget]::Process)
[System.Environment]::SetEnvironmentVariable('INFOPATH',$('/opt/homebrew/share/info'+$(if(${ENV:INFOPATH}){':'+${ENV:INFOPATH}})),[System.EnvironmentVariableTarget]::Process)
$ brew shellenv
set -gx HOMEBREW_PREFIX "/opt/homebrew";
set -gx HOMEBREW_CELLAR "/opt/homebrew/Cellar";
set -gx HOMEBREW_REPOSITORY "/opt/homebrew";
set -q PATH; or set PATH ''; set -gx PATH "/opt/homebrew/bin" "/opt/homebrew/sbin" $PATH;
set -q MANPATH; or set MANPATH ''; set -gx MANPATH "/opt/homebrew/share/man" $MANPATH;
set -q INFOPATH; or set INFOPATH ''; set -gx INFOPATH "/opt/homebrew/share/info" $INFOPATH;
```
The specific case presented in the mentioned discussion could be
mitigated by an additional level of indirection (`{{ output "fish" "-c"
"'brew shellenv'" | trim }}`), that requires that the running system
have the target shells installed, when they are not strictly necessary
with `brew shellenv`.
