Migrate download links off of Google Code, which is soon to be discontinued

[alebcay]

As mentioned here, Google Code will be going into read-only mode later this year in August, and complete discontinuation is scheduled for the end of 2016.

While these dates are a long ways off, it means that sources on Google Code soon may become outdated as the projects move off of Google Code and find hosting elsewhere.

This is a list of Casks in the main repository that currently point to Google Code (homepage or url):

• appmenuboy
• cert-quicklook
• cantata
• colors
• comictagger
• cronnix
• dictunifier
• dukto
• duplicati
• electric-sheep
• epub-to-pdf
• fluke
• fotowall
• ganttproject
• gargoyle
• ichm
• klystrack
• macvim
• maratis
• namebench
• nethackcocoa
• nocturne
• nosleep
• pencil
• port-map
• proximity
• quick-search-box
• quicklook-csv
• quicklook-pfm
• raptor
• secrets
• sequel-pro
• skreenics
• soundflower
• spek
• splitshow
• spyder
• squirrel
• subler
• svnx
• textroom
• the-unarchiver
• time-tracker
• transmission-remote-gui
• tomighty
• tunnelblick
• welly
• wiztoolsorg-restclient
• wjoy
• xld

[anantshri]

my #2cents of help here.

raptor-chess-interface : https://github.com/ddugovic/raptor-chess-interface

arora : https://github.com/Arora/arora

However i was not able to find proper replacement sources hence no pull request.

will add more and if i find a release link will add details in correct place.

[leipert]

It seems like you missed some casks, as the following contain urls with subdomain.googlecode.com and are not in the list above.

[vitorgalvao]

Thank you for the list, @leipert. Moved to the top post.

[leipert]

What happens, once they shutdown and not every project is transferred by their owners.
Are the casks simply discarded or would you try to find a mirror for them?

[vitorgalvao]

They’ll be discarded. Many of those are likely discontinued (like quick-search-box), anyway, and we only accept official links.

It’s completely outside the scope of homebrew-cask to mirror apps. We’re not an archive, and have neither the money nor the resources. If someone else is interested in reviving those products, they’re free to submit them to us, but otherwise it’d be an absolute waste of time and resources for us to do it.

[leipert]

Okay, good to know. A lot of them seem to be for older OSX versions anyway.

[vitorgalvao]

Yep. Removing apps is always good. Many times we have a one-time submission for obscure apps and the cask is never touched again. Having less of them means we can be more effective in keeping everything clean and correct.

[leipert]

Did you ever think about stats, which apps get installed (on a voluntary basis), so that unused casks could be removed automically?

[vitorgalvao]

The idea has been asked and discussed a few times, but always refused. I’m adamant on “no”, for privacy reasons. And if we ask users first (definitely the only correct way to go about collecting this data), then the numbers we get aren’t real anyway, and we can’t trust them.

There’s a long issue on this, but I don’t necessarily recommend you read it. It’s long and frustrating, with the user arguing for it having very broken english and ignoring (or not understanding) the counter points, leading to a lot of the same arguments being made repeatedly, so it’s not a pleasant read.

[leipert]

My oh my. I flew over the issue 💃
Well shame, that casks are not retrieved with an api, otherwise the stats would be there automagically. I see the privacy arguments and I wouldn't recommend a curl with an unique identifier per machine.
The funny thing is, almost every other package service like npm or apt in debian provides the possibility of collecting stats.

Knowing that you are a "no"-advocate, you could get useful results from just a few participants.
You could implement the following workflow (numbers are arbitrary and exchangeable):

1. Every cask has a "last time installed" timestamp
2. If a cask has not been installed for six months, it get's a deprecated flag
   1. If a user, whom allows sending data, installs a cask with a timestamp older than two weeks ▶️ Update timestamp (and remove deprecated flag)
   2. If a cask with deprecated flag is updated ▶️ remove flag
   3. If a cask with deprecated flag is installed by a user, whom does not allow sending data ▶️ show warning, that this cask is deprecated and show him how to remove the flag
3. Each cask that was deprecated for more than two months get's removed

The sending of data would be opt-in and not tied to an account/mac. Even if you opt-in, you won't send data every time. If you are interested in a proof of concept, I would be happy to provide an api.

[vitorgalvao]

npm and apt have control over the packages themselves, though, while we’re just dumb links to outside sources. Not saying that invalidates privacy concerns or anything, but when you have full control over your system, new things are allowed. We’ll never be able to do that, because unlike most package managers we have a huge amount of commercial software, which brings licensing implications.

Also keep in mind I don’t necessarily think we should be removing casks just because they’re unused. It has value that a new user can install homebrew-cask and find the obscure software they use is present. I like when we have less of them to worry about, yes, but removing them just because they haven’t been installed in a while isn’t a good metric. Typically you install apps once; not installing them again does not mean you don’t use it.

Point 2.iii is also not something I’d be happy with. As @alebcay said (second paragraph):

Homebrew Cask (…) aims to be automated. That means as little interactivity as possible (e.g. yes/no prompts, etc.). Asking (…) is therefore not an option.

Anything that gives the user more work should be carefully weighted, and that feels like a punishment (in a light sense, being extra work) for not compromising your privacy (allowing data collection) and to me, the reverse should be true: be privacy conscious, and be rewarded (or at the very least as well served as those who are not).

[leipert]

Well that makes sense :) It's always a balancing act. Thanks for your explanation.

[vitorgalvao]

Closing this issue (migration) in favour of #17075 (deletion).