Allow for more flexibility with multiple versions of the same app

[passcod]

In #114, I hinted at this, and #41 is the original issue. We need some way to support apps that have multiple concurrent builds/versions/channels. Here are the various situations in the Casks library at the moment:

• Firefox has four "channels": Stable, Beta, Aurora, and Nightly. Currently we have two casks: firefox and firefox-aurora.
• We have both Chrome, Canary (which is the equivalent of Aurora for Firefox), and Chromium (which is Chrome without the Google in it).

These are just multiple stable/beta/alpha/nightlies, though. IntelliJ presents a different (but no less worthy) use-case: we currently has a cask each for the Community and Ultimate editions. It would be interesting to combine these!

---

My current proposal would have the formulae look like this:

class SomeCask < Cask
  url 'http://example.com/thing-1.0.0.dmg'
  homepage 'http://example.com'
  version '1.0.0'
  sha1 '...'

  # The devel spec has a version but no checksum
  # (useful when the file changes frequently and w/o warning).
  devel do
    url 'http://example.com/thing-1.1.0-beta.dmg'
    version '1.1.0-beta'
  end

  # The edge spec has no version nor checksum
  # (e.g. nightly builds). Will be installed under `EDGE`
  # as version-path.
  edge do
    url 'http://example.com/nightly.dmg'
  end

  # Specs can be customised (see below for more).
  # Can be useful for e.g. community/closed-source
  # alternates, or unbranded builds.
  spec :alternate do
    url 'http://example.com/thing-1.0.0-alternate.dmg'
    version '1.0.0'
    sha1 '...'
  end
end

Here's how the Firefox cask would be done:

class Firefox < Cask
  url 'http://download.cdn.mozilla.net/pub/mozilla.org/firefox/releases/17.0.1/mac/en-US/Firefox%2017.0.1.dmg'
  homepage 'http://www.mozilla.org/en-US/firefox/'
  version '17.0.1'
  sha1 'a9888ce69440574fabff712549c8ff503fd1acb7'

  # By default, both checksums and versions are required / checked…
  spec :beta do
    url 'http://download.cdn.mozilla.net/pub/mozilla.org/firefox/releases/18.0b3/mac/en-US/Firefox%2018.0b3.dmg'
    version '18.0b3'
    sha1 '31e383782b4fbbcbf3a1ef578d82cbf6861912cb'
  end

  # …and you can disable each separately…
  spec :aurora, :checksum => false do
    url 'https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/firefox-19.0a2.en-US.mac.dmg'
    version '19.0a2'
  end

  # …and also set aliases for ease-of-use / familiarity
  spec :nightly, :checksum => false, :version => false, :alias => :edge do
    url 'http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-20.0a1.en-US.mac.dmg'
  end
end

With options looking like this:

# Predefined specs have predefined switches:
--stable
--devel
--edge

# Custom specs use a more generic syntax:
--spec=aurora

# Aliased specs can be accessed through any name:
--spec=nightly
--edge

# The generic syntax is also valid for predefined specs:
--spec=devel
--spec=stable

---

Please comment! with any ideas, criticisms, completely different proposals, or whatever else. This is quite a rough draft of an idea :)

[patcon]

Wow. This is wild, man. You're a wild-man. Just gave you a ruby and open source endorsement on coderwall :)

[muescha]

brew cask search chrome

• should display all available options

  brew cask install chrome

• should inform me that there are other options available and stop or continue when i press enter

[passcod]

@muescha I'm not so sure about that last one. What if this is used in a script? Should there be a -y or similar option to assume yes to questions like in apt-get? It seems to me like that would be departing too much from the previously established cli style... but that's just me :-\

[patcon]

For what it's worth, I'm more in favour of assuming --stable as default? Least surprising imho.

[phinze]

+1 for a happy path with no interruptions. While there are some places
homebrew interrupts for user input (e.g. brew uninstall when there are
multiple versions present), IMHO the "homebrew way" optimizes for a
frictionless default experience.

I'd much rather do a notice as the user installs that there are other
options for this particular cask. Then the user is welcome to brew cask uninstall and reinstall with other options. To me, this is an instance of
the common UX recommendation to allow undo rather than present modal
interruptions. [1]

[1] http://alistapart.com/article/neveruseawarning

On Mon, Jan 28, 2013 at 6:20 PM, Patrick Connolly
notifications@git.luolix.topwrote:

For what it's worth, I'm more in favour of assuming --stable as default?
Least surprising imho.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/142#issuecomment-12815508.

[muescha]

@phinze aggree with you: just an information about the other versions while install and a hint to uninstall and reinstall

[neersighted]

👍

[ioerror]

In an ideal world, we'd also have LANG/LOCALE checks that download the right version of the software - if there is such a version - while also defaulting to a safe language or something to get it installed at all. TorBrowser for example isn't localized like a normal project, so we have the same problem as firefox basically. One .xpi per language that must be added to the default baseline Firefox. Whee.

[passcod]

Firefox has different downloads for different locales, not sure if that's what you mean or not. I'm sure custom flags (for locale, architecture, etc) are needed, pulling data from the env (LANG, LC_*, …) could also be considered but there are slightly more complex implications (the formula's behaviour could now change “invisibly,” and the disparities in people's envs would make troubleshooting significantly harder).

[ioerror]

What I mean is that Tor offers Tor Browsers like so:

https://www.torproject.org/dist/torbrowser/osx/TorBrowser-2.3.25-2-osx-i386-en-US.zip
https://www.torproject.org/dist/torbrowser/osx/TorBrowser-2.3.25-2-osx-i386-es-ES.zip

[gebba]

I would love to see this happen! I'm a huge "early access" and nightly junkie, and it would be nice to have a sweet way of managing it through cask. 👍

[phinze]

Me too @gebba - I think this will be the next big feature to land. ✈️

[jfsiii]

👍 (and to make sure I get notified when this lands)

[patcon]

@jfsiii https://www.evernote.com/shard/s27/sh/ee091d06-2cb2-4935-9278-4a3d0bfd3a32/da6c46fe553ab4daab1c4568942a95b9 :)

[jfsiii]

@patcon orite

[ciarand]

As per #212, Sublime Text 3 is now open to the public, regardless of registration status. I've got a sublime-text3 cask that's checksum'd for the current build (3047), but I'd obviously prefer to use a --beta flag or similar. What's the status on this issue?

Update: For those interested, here's a fork with the ST3 cask while we wait for this PR to hit.

The cask looks like this:

class SublimeText3 < Cask
  url 'http://c758482.r82.cf2.rackcdn.com/Sublime%20Text%20Build%203047.dmg'
  homepage 'http://www.sublimetext.com/3'
  version '3047'
  sha1 'cf20f30d0b0d406ced76784d9bdd63f817868f74'
  link 'Sublime Text.app'
end

[passcod]

I'm not going to spend more time on here this evening, we'll just have to agree to disagree. Besides, it's @nanoxd's feature now.

[vitorgalvao]

@benjaminhawkeslewis Regarding your first point

Installing a specific version. For example, a user might only have a licence for an older version (ExpanDrive 2 not 3), or have an older system that can only run an older version, or want features present in an older version (e.g. Opera 17 is missing features in Opera 12).

Even though this would be the appropriate solution for older apps (and this is certainly the issue to discuss that), homebrew-cask has typically been concerned with the newer versions (two quick examples of this are Alfred and TextMate, where we outright abandoned v1 for v2), and in those discussions (can’t seem to find them right now) there is some reasoning as to why. I’d prefer to find those discussions instead of repeating everything, specially since some of he reasoning may no longer apply, but some of it is certainly worth considering.

[jansauer]

+1 I would really like to see support for older versions and nightly builds.

[vitorgalvao]

+1 I would really like to see support for older versions (…).

I have no doubt there is some demand for this, the question is if it is enough to justify the work. We discussed this about Alfred, and even though that pertained to a specific case, it’s still somewhat relevant. The comment by @hanjianwei seems to me like the best approach to this.

[saulshanabrook]

I actually rather like have the different chrome versions completely separate. For me it is nice to be able to see what apps have beta versions and what do not. Although appending the version to the package name, chrome-canary isn't as clean as chrome --HEAD, it is much more explicit and obvious.

What are the use cases for having these flags instead of separate formulas?

[passcod]

@saulshanabrook The search and list commands c/would be adjusted to display the various versions available, so I think your desire for visibility of versions would be satisfied either way. A single file for everything makes it easier to maintain and keep track of, as well as allowing to share configuration (if all that changes is the URL and version, for example, but the install/uninstall/etc sections stay the same…). Also, I think historically chrome-canary and firefox-aurora made it in because the project was young, we don't see that many betas and alphas get in nowadays (correct me if I'm wrong, maintainers :), this feature might make these more easily accepted.

[pavel-sakun]

I'm actually thinking of creating some kind of repository like Python package, Roby Gems, Node.js's NPM does. I see number of pull requests you are getting and I bet at some point it become really hard to manage although pull requests itself are pretty straightforward by itself (update version, download link and checksum, or any of them in different combinations). Also I'm thinking about automated way of updating recipes...this should reduce number of pull requests dramatically. At the moment they are just ideas...

[victorhooi]

I just wanted to check - is using https://github.com/caskroom/homebrew-versions the currently recommended way of doing this? (#4332 seems to imply so).

Or has there been any changes in terms of getting this in home-brew-cask itself?

[webavant]

#4332 worked for me.

[cherrot]

#4332 works:

$ brew tap caskroom/versions
$ brew cask install google-chrome-dev

[vitorgalvao]

Different repos is likely the best we have, and will continue to be for a long while, until/unless we revamp the system.