Batch Rip Actions for Automator

[plessbd]

used for ripping and encoding your physical media

[jawshooah]

Are cask dependencies a thing? Seems like this requires a few external applications/libraries, and while it provides download links in the menu bar, I'm sure most people (myself included) would prefer to install any dependencies via brew/cask.

[jawshooah]

This could also do with a zap stanza, what with everything it dumps into ~/Library/Services.

[plessbd]

I added a zap stanza. I could not determine how to do a depends_on other casks though.

[vitorgalvao]

It’s not yet possible to depends_on other casks, but it is planned. I agree with @jawshooah: if other apps are needed, we should hold merging this a bit.

[plessbd]

how about a caveat that tells you what you need to do until depends_on is supported. Seems like a good compromise, especially since there are "options" depending on what you actually need / want to do with these actions.

[vitorgalvao]

We can start building it like if depends_on :cask were already available, because it will be, soon.

[plessbd]

I know with homebrew you can pass options, is there a way to do this with cask?

Specifically, I do not have a Blu-Ray player and I have already ripped the DVD to the vob files, all I need is encode capabilities.

So I would prefer to not install the bluray or libdvdcss packages.

If I just missed something in docs please let me know.

[vitorgalvao]

I know with homebrew you can pass options, is there a way to do this with cask?

Not yet. We could err on the side of caution and simply require them all. However, your caveat is explicit, and could also work fine (I definitely see your point to not install the extra cruft). I don’t have a strong opinion on this one, so I’ll ping @rolandwalker @ndr-qef and @claui, and defer the decision.

[rolandwalker]

Hi @plessbd !

Homebrew has a way to define soft (recommended) dependencies as well as hard (required) ones. We are just in the process of implementing hard dependencies, but I'm sure we can get to soft dependencies in time.

Meanwhile, the caveats seem good to me. The software works without those items, and you have gone the extra mile to show users how to get more functionality.

However – since #6570 we have started being more careful about what we include here. Our standards are fairly simple in that we want software with a clearly identifiable vendor who stands behind their work. Dropbox URLs are undesirable, but workable when they cannot be avoided. But a forum posting is just not enough for a homepage.

This stuff is not fully documented as we are still hashing out the boundaries, and the main repo is not even fully compliant with the parts we have decided.

Could we find an identifiable vendor for this cool Cask? Or send it to homebrew-unofficial ?

[vitorgalvao]

@rolandwalker I see skii as a different matter — it once had a vendor and now it does not, raising suspicion on the new domain owners, who seem to be squatters. Going back to the argument of “we’re not a discoverability service, so you actually need to know what you’re getting into”, skii might be dangerous now because people who knew about it before may try to get it now, and we have no idea if who’s serving it is trustworthy, but it is not who users expect to be.

This, however, along with kext-wizard and ninjablocks¹ always had a forum post as its home, so if a user knows about it, they should be familiar with where it came from.

---

¹ Actually that one may need a revision, as that might be an unofficial build.

[rolandwalker]

I, personally, follow your logic perfectly, but it's too much context for a simple rule that everyone can use.

Similar to your point about clarifying licensing by narrowing our view to the binary itself, knowing where a Cask goes shouldn't require knowledge of history. We should be able to look at the Cask and say: "Forum posting. This critter is vendorless. Unofficial."

Otherwise we have a situation where a forum posting goes in the main repo if it has never had a vendor, but into unofficial if it had a vendor once upon a time. Not only hard to remember, but arguably backwards in terms of degree-of-trustworthiness.

kext-wizard and anything without a vendor should migrate to unofficial. And it is relevant to skii, inasmuch as forum postings are a common distribution mechanism for malware. (Nothing against kext-wizard; I use it myself.)

[vitorgalvao]

Agreed. @plessbd Could you please submit this to caskroom/unofficial instead?

[plessbd]

Done
https://github.com/caskroom/homebrew-unofficial/pull/31