This adds a `UsesOnSystem` class to `OnSystem`, containing boolean
instance variables to indicate which types of on_system methods are
used in a formula or cask. This is intended as a replacement for
`@on_system_blocks_exist`, which doesn't allow us to determine what
kinds of on_system calls were used. This provides more granularity
but we can still use `@uses_on_system.present?` to determine whether
any on_system calls were used (and this doubles as a `nil` check in
`Formula`, as the `self.class` instance variable has to use a nilable
type).
The `UsesOnSystem` instance variables cover the current
`ARCH_OPTIONS` and `BASE_OS_OPTIONS`. At the moment, we mostly need
to tell whether there are macOS/Linux or Intel/ARM on_system calls,
so I've omitted instance variables for specific macOS version until
we have a need for them.
As a practical example, if you wanted to determine whether a cask
uses Linux on_system calls, you can call
`cask.uses_on_system.linux?`. The `linux` boolean will be `true` if
the cask has an `on_linux` block, an `on_system` block (which requires
Linux), or uses `os linux: ...`. This is something that would be
challenging to determine from outside of `OnSystem` but it's
relatively easy to collect the information in `OnSystem` methods and
make it available like this.
Import these from the homebrew/aliases tap and deprecate that tap.
This required a little messing around with class/module/constant names
to get `brew tests` and `brew typecheck` to play nicely.
I added also added Sorbet type signatures and integration tests.
Allow the ability for a system administrator to use
`HOMEBREW_BREW_WRAPPER` and `HOMEBREW_FORCE_BREW_WRAPPER` variables to
enforce the usage of a particular `brew` command for non-trivial (e.g.
`brew --prefix` is considered trivial, it doesn't need to write to the
prefix) Homebrew commands.
This also introduces a `HOMEBREW_ORIGINAL_BREW_FILE` variable for some
internal usage; `HOMEBREW_BREW_FILE` was being used internally for
both "how should we shell out to Homebrew" and "what should we use
to check permissions on Homebrew". `HOMEBREW_ORIGINAL_BREW_FILE` is
now used just for the latter case.
Inspired by conversation in
https://github.com/Homebrew/homebrew-bundle/pull/1551 which suggested
this was worth fixing in wider than just `brew bundle`.
- `reinstall` and `upgrade` no longer mark as installed on request,
with or without names specified, but preserve the version from the
tab instead
- default `install_on_request` to `false` rather than `true`
- only set installed in request in a tab if it's missing rather than
false
Co-authored-by: Michael Cho <michael@michaelcho.dev>
If you have `HOMEBREW_TEMP` set to a longer path (e.g. the user's
private temporary directory rather than `/private/tmp`), Sequoia will
error out on some tests when forking because the path is too long
(> 104 bytes).
To improve this situation let's:
- use a shorter path for `HOMEBREW_TEMP` by appending `/brew-tests` to
the existing `HOMEBREW_TEMP` used outside of tests rather than
creating nested temporary directories
- use the minimal amount of randomness to avoid collisions while
allowing parallel tests
- use `squeeze` to remove any double slashes in the temporary path
This should avoid these getting included globally in future.
I found this list from a combination of
https://github.com/Homebrew/brew/pull/17707/files, looking at the
Gemfile and just looking around myself.
Loading different constants can be tricky with all the requires in
Homebrew so we want to strengthen the existing checks to make
sure that things are not getting required when there is a performance
penalty. This expands the existing check to include more constants
beyond `Formula` that we don't expect to be defined and that pull
in a lot of other dependencies.
- Move HOMEBREW_TAP_DIRECTORY to startup/config.rb because this file
holds more of the directory constants
- Rename `Commands.cmd_directories` to `Commands.tap_cmd_directories`
to better express that the commands come from taps
This file has the directory constants while the other one has regexes.
Just better organization.
We were selectively requiring the tap.rb file in a few places for
performance reasons. The main method we were referencing was the
`Tap.cmd_directories` method which uses `Pathname` and the `TAP_DIRECTORY`
constant internally. `Tap.cmd_directories` is mostly used in the `Commands`
module and that is loaded very early on in the program so it made sense
to move that command to that module. To facilitate that I moved the
`TAP_DIRECTORY` constant to the top-level and renamed it to
`HOMEBREW_TAP_DIRECTORY`. It now lies in the tap_constants.rb file.
A nice bonus of this refactor is that it speeds up loading external
commands since the tap.rb file is no longer required by default in
those cases.
