Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate the Ruby backend from internal Homebrew dependencies #5080

Closed
rolandwalker opened this issue Jun 26, 2014 · 6 comments
Closed

Separate the Ruby backend from internal Homebrew dependencies #5080

rolandwalker opened this issue Jun 26, 2014 · 6 comments

Comments

@rolandwalker
Copy link
Contributor

Background

Homebrew-cask is implemented as a Homebrew external command, in the form of
brew-cask.rb, which is required by the brew command. This means that
Homebrew-cask has full access to, and is constrained by, the Ruby runtime
provided by Homebrew.

Initially it was thought that Homebrew-cask would re-use much of Homebrew's
code internally. That turned out not to be the case in practice, largely
because Homebrew's code is organized around the Formula.

Proposal

brew-cask.rb should be re-implemented as an executable brew-cask, which
would be invoked by Homebrew rather than required. brew-cask would
then execute completely independently of Homebrew's Ruby environment.

This would be an internal-only change. The user interface would stay the
same. Commands would still be invoked via brew cask <verb>, and we would
still piggyback on brew update to get new Casks.

Advantages

  • Stability. Homebrew does not guarantee any internal APIs.
    Homebrew-cask frequently breaks due to changes within Homebrew
    (force UTF-8 encodings #4732, Adjust to Homebrew's test environment changes #4982, Defend against unusual Homebrew setups #4229, many others).
  • Clarity. Where we do re-use Homebrew's classes (such as for
    downloading), we do so only partially, with some methods overridden.
    This needlessly obscures what the code is doing, making it more difficult
    to diagnose bugs or develop new functionality.
  • Error Reporting. Both Homebrew and Homebrew-cask attempt to
    rescue exceptions and direct users to the relevant issues URL. @voanhduy1512
    did some good work on this problem, but it still crops up as in Update error #5108. Every
    misdirected report is a drain on maintainers (in both projects).
  • Cleanup. Currently brew cask cleanup works in a roundabout
    way (using tracking symlinks) because we share a download location
    with Homebrew. It would be more robust to maintain our own download
    cache.
  • Ruby 2.0. We would have the choice to be more aggressive about
    switching to Ruby 2.0 (say, 6 months after Yosemite is released). We
    could require Mountain Lion and earlier to install Ruby 2.0 as a
    prerequisite. This would not only gain us access to new language
    features, but reduce the currently-imposed burden of maintaining
    compatibility across Ruby 1.8 and 2.0.
  • Freedom. Currently we are constrained by Homebrew's decisions with
    regard to character encodings, interpreter version, monkeypatching -- all
    things that, once inherited, we cannot easily undo.

Disadvantages

  • Tap Migration. We have sometimes used internal interfaces to Homebrew
    which are not available externally, as with the tap migration code (automatically transition to new Tap name/location #4169).
    However, this also could have been accomplished by copying the relevant
    logic from Homebrew.
  • Integration for files in /usr/local. Some Casks install files into /usr/local,
    which causes brew doctor to complain as in Installing truecrypt makes 'brew doctor' unhappy #2350 and others. Currently
    we have a caveats warning for this, which is not really a fix. As mentioned
    in Cleanup after Truecrypt installation #3693, we could fully resolve the problem by installing files to a Homebrew
    Cellar, and then symlinking into the Cellar as with any other Homebrew
    installation. Such a technique would become more difficult if we could not
    call directly into Homebrew.
    • However, it also seems that nobody is working on that implementation.
    • There are other possible approaches, such as generating an ad hoc Formula.

Places where we currently re-use Homebrew's code (incomplete)

Tracker

Edits:

  • added Disadvantage / Integration for files in /usr/local
  • added Tracker
  • added Error Reporting
  • renamed Plan to Tracker; filled out Tracker details
@muescha
Copy link
Contributor

muescha commented Jun 26, 2014

and add:

Advantages:
standalone: just install cask without the need to install brew

@vitorgalvao
Copy link
Member

just install cask without the need to install brew

Not exactly. From the post:

we would still piggyback on brew update to get new Casks.

@muescha
Copy link
Contributor

muescha commented Jun 26, 2014

if brew is in stalled then piggyback on brew update and for without brew add a cask update

@rolandwalker
Copy link
Contributor Author

cc @phinze

phinze added a commit that referenced this issue Jun 29, 2014
phinze added a commit that referenced this issue Jun 29, 2014
phinze added a commit that referenced this issue Jun 29, 2014
rolandwalker added a commit to rolandwalker/homebrew-cask that referenced this issue Jul 31, 2014
According to the logic of Homebrew#5080, we should move away from calling
Homebrew internals, in part because things break over time, as
happened here with the implementation of `depends_on_formula`
(shortly to become `depends_on :formula`).

This re-implements formula dependencies by invoking the Homebrew
CLI, which is the only stable API Homebrew guarantees.

Fixes Homebrew#5475
Fixes Homebrew#4010
@rolandwalker rolandwalker self-assigned this Dec 13, 2014
@vitorgalvao
Copy link
Member

@jawshooah Since we now want to go in the opposite direction, should we close this, or is it still useful in some way?

@jawshooah
Copy link
Contributor

No use in leaving it open.

@miccal miccal removed the roadmap label Dec 23, 2016
@Homebrew Homebrew locked and limited conversation to collaborators May 8, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants