Just ran through this and quite enjoyed it. It's very different from "A Tour of Go". I really like how he creates a narrative out of test failures. It's by no means effective as a sole source for learning Go, but I'd recommend it to those who have completed the Tour as a way of getting more practice working with Go's various data types.
> What is the difference between the cask installation suggested in the link and the cask installation procedure suggested on the cask home page?
Two differences. One is that we moved to an org repo, so the first form is relying on the github redirect from the move. The other is that the second form relies on the semi-recently introduced "auto-tap" syntax in homebrew.
Functionally they will get you to the same place (we've got code to notice that your remote is pointing to the old repo location and update it), but the second form is newer and cooler. ;)
Hey there! This is a valid concern, but I don't think it's all that different from using Homebrew. The community maintains the cask definitions, and all pull requests are reviewed via the project team. There's a checksum verification feature built in, though we're still figuring out how to reconcile that with un-versioned download URLs [1].
At the end of the day, when you use any package management software, you are implicitly trusting the team that maintains said software. Perhaps it would be better for us to do our best to force users to make that trust more explicit? It's an interesting question - any suggestions you have would be more than welcome - feel free to open an issue to discuss! :)
Hiya - author here. Thanks for the feedback on this stuff! It's always good to hear where it's best to focus improvements.
I'm going to address a few of your points specifically.
> There are no upgrades, in many cases it doesn't work.
It's true that `brew cask upgrade` is not yet a thing. I would very much like it to be. I've been sort of avoiding work on the feature for fear of messing it up. But that's no reason to not try to make something work! :) Maybe I'll use this as an occasion to start digging in and getting my hands dirty.
> At the end of the day, it duplicates some of the Homebrew functionality - some non-GUI packages are getting into Cask, because possibly Homebrew doesn't want them - it's a bit confusing as well.
If the purpose of the project is not clear, that's definitely a problem. I'm not aware of many (any?) purely non-gui apps making it in to Cask. The `Homebrew/homebrew-binary` tap is the place for those. I'll go review our included Casks to make sure things are clear.
> I think efforts should be put into merging into Homebrew instead of keeping it separate.
I can understand this opinion, but I think we may actually end up going in the other direction. The places we share code with Homebrew have been the biggest problem areas for us. We are already 90% code independent from Homebrew, and I think moving Cask to its own world may benefit both the project and the users. But of course that's a conversation to have with the (amazing!) project team.
Alas there is not AFAIK. For all the research I've done on this, the only conclusion I've been able to draw is that the MAS is anti-automation (if not in intent, at least in its current design). :(
> I just want the applications to be copied to my install location and left alone.
If it's a use case that would be useful to people, this is a mode of operation I would definitely be willing to include in the project. Feel free to open an issue (or even better - a PR!) with the idea. :)
I've thought about this, previously I've changed this by just replacing your /bin/ln calls to mv but I think that attempting to add this to the tool may cause some confusion. Obviously it wouldn't be the default behavior and you'd have to enable it probably through the ENV variable, but this would render all commands but install virtually useless I think which wouldn't make much sense in its current state I don't think.
> Quite a few of the apps I use (iTerm2, ST3, Chrome, Adium, etc.) update themselves periodically. I wonder how Cask deals with that?
Sparkle-based self-updating apps will self-update in place. For apps like that, the current policy is to have a Cask version of 'latest', and letting the apps self update.
I've been doing this for some time and I've found it works out AOK. It's nice to be able to click the "Update & Relaunch" and know I'm not messing anything up. :)
