You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Provide a detailed description of the proposed feature
Currently, we use SimulateSystem in a few places to allow us to evaluate on_system blocks without having to change physical machines. This would extend that to allow us to simulate the system version. The difficult thing would be adding this in in such a way that it doesn't break current installs/builds when people are simulating things (using environment variables for instance).
What is the motivation for the feature?
This is needed to easily and accurately evaluate if a cask/formula runs on a specific OS. We could use this information to exclude unsupported OS versions from audits and the like.
How will the feature be relevant to at least 90% of Homebrew users?
It would potentially reduce CI time somewhat since audits take less time and some command output would be more relevant since it could skip over unsupported casks/formulae. I haven't looked at CI though so I'm not sure if it will be relevant there.
What alternatives to the feature have been considered?
Option 1
We could mandate not defining depends_on macos: inside on_system blocks and only define them in the base level of the cask. This would require a new linter rule but then we wouldn't need to simulate anything to get the macOS version requirement for a cask.
For example, Homebrew/homebrew-cask#154556 changed some PRs to use the version array syntax which while being slightly more verbose ends up allowing us to tell the supported OS versions without simulating anything.
depends_onmacos: [:catalina,:big_sur,]
Option 2
We could rewrite the on_system DSL to automatically update a global MacOSRequirement for each on_system stanza. This would be a bit magical though and would require changing a large number of casks along with adding new linter rules but would just work without forcing people to think about where to put the depends_on macos: rules.
The text was updated successfully, but these errors were encountered:
Verification
brew install wget
. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.Provide a detailed description of the proposed feature
Currently, we use
SimulateSystem
in a few places to allow us to evaluateon_system
blocks without having to change physical machines. This would extend that to allow us to simulate the system version. The difficult thing would be adding this in in such a way that it doesn't break current installs/builds when people are simulating things (using environment variables for instance).What is the motivation for the feature?
This is needed to easily and accurately evaluate if a cask/formula runs on a specific OS. We could use this information to exclude unsupported OS versions from audits and the like.
Recent discussion in:
How will the feature be relevant to at least 90% of Homebrew users?
It would potentially reduce CI time somewhat since audits take less time and some command output would be more relevant since it could skip over unsupported casks/formulae. I haven't looked at CI though so I'm not sure if it will be relevant there.
What alternatives to the feature have been considered?
Option 1
We could mandate not defining
depends_on macos:
insideon_system
blocks and only define them in the base level of the cask. This would require a new linter rule but then we wouldn't need to simulate anything to get the macOS version requirement for a cask.For example, Homebrew/homebrew-cask#154556 changed some PRs to use the version array syntax which while being slightly more verbose ends up allowing us to tell the supported OS versions without simulating anything.
Option 2
We could rewrite the
on_system
DSL to automatically update a globalMacOSRequirement
for eachon_system
stanza. This would be a bit magical though and would require changing a large number of casks along with adding new linter rules but would just work without forcing people to think about where to put thedepends_on macos:
rules.The text was updated successfully, but these errors were encountered: