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`.
I've been doing this personally for a few months and not hit any bugs.
We already do this for `brew tests`.
It will allow us to:
- remove manual type checks from all developer commands (Sorbet does a
better job with these)
- better surface bugs
- better surface type signatures
- get closer to being able to enable this by default for everyone
Instead of doing so literally whenever we query for a formula, Instead
do so only when we're in an auto-updateable command.
This better fits the existing behaviour while still updating when it's
most important to do so.
This sets the default and allows customising how often we try to
download files from the API.
This does not affect `brew update` as we want to always check every time
on an explicit call.
