Add VLC.app 2.2.0-20140520 (nightly build)

[sorbits]

The VLC nightlies site does offer a last URL pointing to the most recent nightly build, but neither content type nor extension indicate that this is a zip archive, so it does not seem usable with cask (unless one can specify the content type in the formula).

I used the date in the version string (which is also in the URL) even though VLC.app is built as version 2.2.0-git.

[vitorgalvao]

Yes, you can specify the container type, but homebrew-cask is pretty good at detecting it anyway. If you submit that version, we can possibly work it out to work.

[sorbits]

I have updated the commit for this pull request to use the symbolic URL and (per cask audit) changed the version string to latest.

And homebrew-cask did indeed correctly sniff the archive type.

[vitorgalvao]

Having the directory display the version number can be an issue in the future. However, it would be a shame to have a versioned nightly when an alternative exists.

[sorbits]

I don’t understand this comment. There is no version number stated for this formula (other than latest).

The mention of 2.2.0-git is in the downloaded zip archive.

[vitorgalvao]

Exactly. Which means the cask will break when the nightly is updated, since the directory's name will change but homebrew-cask will be looking for the old one.

[sorbits]

You mean it will break once VLC 2.2.0 is released and the nighly builds
change to 2.1.0-git, right?

The only way to avoid the breakage is to not use latest but instead a
specific nightly build (as my first PR did), but then the formula has to
be updated each time a new nightly build is released, rather than only
when a new VLC major version is released.

On 14 Jun 2014, at 17:33, Vítor Galvão wrote:

Exactly. Which means the cask will break when the nightly is
updated, since the directory's name will change but homebrew-cask
will be looking for the old one.

---

Reply to this email directly or view it on GitHub:
#293 (comment)

[vitorgalvao]

Precisely. Amidst the other version references in the previous PR, I’ve missed this problem with the linked app.

@rolandwalker Just to confirm, we don’t currently have a way to go around that, do we? Seeing as said directory is the only one inside the .zip.

[vitorgalvao]

Having a closer look at the page where they link to the nightlies, it seems like we can get this to work fairly easily.

class VlcNightly < Cask
  latest_num = %x{ curl --silent 'http://nightlies.videolan.org/build/macosx-intel/' | grep 'x86_64' | tail -1 }.strip.gsub(/.*>vlc-(.*?)-.*/, '\1')

  url 'http://nightlies.videolan.org/build/macosx-intel/last'
  homepage 'http://www.videolan.org/vlc/'
  version 'latest'
  sha256 :no_check
  link "vlc-#{latest_num}-git/VLC.app"
end

Basically, this gets and parses the page for the actual version number, so it can replace it in the directory’s name. Tested on a clean Mavericks VM, worked without a hitch. This way we can get the best of both worlds.

[rolandwalker]

That's a good trick, but (having seen this on some other Casks), I'd like to add something to make it easier. How about

  link '*/VLC.app', :expand => :first

[vitorgalvao]

Sounds good. It’s precisely the type of functionality I had in mind. Making it work with every part of the path could also potentially be useful with those pesky apps that have a version number in the bundle itself, but perhaps that is a non-problem, as I’m not sure any of those has an always up-to-date url.

[sorbits]

Is this pull request awaiting glob support in cask?

Otherwise I’d suggest merging the simple version and update the file path to include the asterisk once cask ships with this feature.

[rolandwalker]

@sorbits, I haven't fixed on the right interface for glob support; there is only a rough version in Homebrew/homebrew-cask#5043. That's weeks away, so I don't think we should wait it.

@vitorgalvao the problem with the solution you gave above is that the shell command
would run every time the Cask is loaded, slowing down every operation that might
instantiate this Cask. Previously a number of Casks did this sort of thing, but it caused
performance problems, so they were eliminated. This is also why we document that
conditionals within Casks must be efficient.

In this particular case, curl can take very long to complete if something goes wrong.

So for now, I think we should merge this and try to keep it up-to-date.

[vitorgalvao]

Will be merged in #327 (still credited to @sorbits), with the latest version.