Formulae that depend on `node` sometimes contain files that use a
shebang like `#!/usr/bin/env node` and this can lead to issues when
the `node` in a user's environment isn't brewed `node`.
For example, some node modules are compiled when the formula is built
but if the user's `node` is a different major version than brew's
`node`, the differing `NODE_MODULE_VERSION` can produce an error when
certain parts of the application are used. The formula may build and
test fine and the issue may only become apparent when more of the
application is exercised.
This adds a `Language::Node::Shebang` module (borrowing from the
existing Perl and Python examples), which allows us to use
`rewrite_shebang detected_node_shebang, ...` in formulae to address
this type of issue.
If a formulae or cask is marked as both added and deleted, we've just
incorrectly detected it. Remove it from the report.
This can happen when a formula or cask is moved around in the repository
e.g. with sharding.
- Fix cask info output being incorrect
- Improve some code referring to casks as formulae
- Move livecheck cask fixtures to not shadow existing names
- Adjust the cask tap symlinking logic to make handling outdated
shadowed casks significantly easier
- Fix various flaky tests caused by casks sharding logic
- Prefer longer paths when there's multiple formulae or casks in a tap
with the same name rather than always using the first
Clarify that the deleted formulae/casks when not using `report_all`
are only those that have been deleted _and_ the user has them
installed. This should avoid users glossing over this information as
it is pretty relevant to them.
While we're here, refactor some of the `report_all` logic to make it
easier to remove it all on the next Homebrew major/minor version.
`dyld` uses the target library's install name to work out whether this
is a Framework or a dylib, which affects how `dyld` searches for the
desired library.
We should therefore avoid confusing `dyld` by including the
`*.framework` part of the install name in the target dylib, which is
what this change does.
Here's a concrete example of what this changes. Before:
❯ otool -L /usr/local/bin/python3
/usr/local/bin/python3:
@loader_path/../Python (compatibility version 3.11.0, current version 3.11.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
After:
❯ otool -L /usr/local/bin/python3
/usr/local/bin/python3:
@loader_path/../../../../Python.framework/Versions/3.11/Python (compatibility version 3.11.0, current version 3.11.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
By retaining the `Python.framework` part of the install name, we make
sure that `dyld` knows that it should be looking for a framework rather
than a dylib.
This is just a recipe for infinite loops. Plus, recursive references are
likely to be invalid, so we don't really gain much by attempting to
resolve them.[^1] (But we could if we made the logic here much more
complicated.)
Fixes a CI failure seen at Homebrew/homebrew-core#138323.
[^1]: See, for example, embree/embree#455.
Even though the command already sets without_api that only
affects how named args are loaded. In this command, we used to load
many formulae and casks all at once using the API according to
user settings. Now we just mandate that all loading must skip the API.
- Load paths with no API when needed (e.g. for `brew edit`)
- Use no API mode for `brew log` as it's needed there
- Define sharding format for homebrew-cask and homebrew-core inside
`Tap` methods
- Create new formulae/casks in location defined by these `Tap` methods
- Fix a bug in Formulary that made sharded formulae lookup less
efficient (and possibly broke it for core and some API usage)
- Fix various other hardcoded Formula/Cask directory assumptions
Co-authored-by: Bo Anderson <mail@boanderson.me>
I noticed from
https://github.com/Homebrew/homebrew-core/actions/runs/5751070010 that
we're no longer creating reproducible bottles between macOS and Linux.
All macOS checksums have changed but Linux ones have not. The main
difference between the two platforms is the `gtar` version used so let's
always just use the formula on both platforms.
While we're here, clear up the ordering and comments a little on the
reproducible `tar` arguments so that it's easier to compare with the
reproducible builds archives documentation.
Fixes error seen in Homebrew/homebrew-core#138452.
`DevelopmentTools.default_compiler` can return a `Symbol` like `:clang`.
Make sure its result can be fed to `DevelopmentTools.locate`.
Signed-off-by: Ruoyu Zhong <zhongruoyu@outlook.com>
