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
Since formulae cannot depend on casks, we would no longer be able to have android-platform-tools or android-commandlinetools as prerequisites. As has been pointed out in skip checkup fails unless users manually install Android Studio #606, these dependencies are of dubious value since we still rely on a local Android Studio install anyway. But we would need to perform testing to ensure that these dependencies are not needed for other reasons.
The current Cask setup means that the Skip build plugin and the local skip command are using identical binaries for any given release. This would no longer be the case, since we would continue building the skipstone plugin ourselves (we have to, since we need to publish the SHA-256 of the plugin when we update the skip.git tag), but Homebrew would be building the skip command that is run on macOS and Linux. This should be fine, since skipstone as run by the command plugin and skip as run by the user are typically running different operations, but it is possible that divergent builds could have unanticipated consequences.
Homebrew manages its own build cycle, and while it is generally pretty quick to pick up new release tags and "bottle" the formula, it isn't as instantaneous as our own release process which will synchronize the availability of the plugin with the available of the equivalent corresponding skip tool release. This means that any rapid bugfixes or patches that we want to get out in a timely fashion could be delayed by Homebrew's own processes.
When building locally for the Skip Linux Cask, we use the static Linux (musl) cross-compilation SDK, whereas Homebrew's formula can build directly on Linux. musl and Linux should behave identically, but there are differences in how some things work (specifically, linking to the system libcurl/libxml2/libz for the normal Linux build versus using the Static Linux SDK's own statically linked versions of those dependencies).
None of these issues should be blockers to the migration, but they do require thought. We also need to determine whether the benefits of a simplified brew install skip are worth the effort.
The standard skip installation performed with
brew install skiptools/skip/skipuses the release process described in the skipstone Release docs, which involves creating a release build, uploading it to https://github.com/skiptools/skip/releases, and updating the binary Homebrew cask at https://github.com/skiptools/homebrew-skip/blob/main/Casks/skip.rb.Now that skipstone is open-source, we could convert distribution into an official Homebrew formula instead, which would have the following benefits:
brew install skipinstead ofbrew install skiptools/skip/skipA trial run of this is promising in the following (scrapped) PR: Homebrew/homebrew-core#267108
However, there are a few considerations:
android-platform-toolsorandroid-commandlinetoolsas prerequisites. As has been pointed out inskip checkupfails unless users manually install Android Studio #606, these dependencies are of dubious value since we still rely on a local Android Studio install anyway. But we would need to perform testing to ensure that these dependencies are not needed for other reasons.skipcommand are using identical binaries for any given release. This would no longer be the case, since we would continue building theskipstoneplugin ourselves (we have to, since we need to publish the SHA-256 of the plugin when we update theskip.gittag), but Homebrew would be building theskipcommand that is run on macOS and Linux. This should be fine, sinceskipstoneas run by the command plugin andskipas run by the user are typically running different operations, but it is possible that divergent builds could have unanticipated consequences.skiptool release. This means that any rapid bugfixes or patches that we want to get out in a timely fashion could be delayed by Homebrew's own processes.None of these issues should be blockers to the migration, but they do require thought. We also need to determine whether the benefits of a simplified
brew install skipare worth the effort.