Scripts are now available as casks

[vitorgalvao]

I’m submitting this as an issue instead of a PR because I don’t know where, if, and how much of this information you’d like to include. If you want to give me some pointers in that regard, I can work on a first draft.

The scripts in this repo are now available as casks. What this means is if you have homebrew-cask installed, you can brew cask install convert-video detect-crop query-handbrake-log transcode-video to install them all at once (or pick just some, naturally), with their respective dependencies.

All the dependencies are satisfied via homebrew and homebrew-cask, according to the table in the README. The only difference is handbrakecli as these casks, when depending on it, will install handbrakecli-nightly instead, since you seem to favour it. If you believe the non-nightly version should be installed by default instead, please let me know so the correction can be made.

I’ve set them all as version 5.3 since they all download the same package (the complete source from github) and this gives some consistency to track them. Their sha256 will, naturally, need to be updated with your changes (even changes to the README, now that I think about it).

When installing these with homebrew-cask they’ll be slightly renamed (will lose the trailing .sh), and be linked by default to /url/local/bin (can be easily changed at install time with the --binarydir flag).

We haven’t yet implemented an upgrade verb, though, which means that to install an update, you need to know it exists and tell homebrew-cask to download and install the new version.

[lisamelton]

Vítor,

Thank you for making a cask of my scripts. I was just asked about something like this on Twitter today. :)

Why are you renaming the scripts on installation? I don't want my scripts to be renamed in this fashion as it will make it very fragile for me to ever have one call the other, something I was considering for the future. So, I can't endorse the project with that behavior.

Also, please don't install handbrake-nightly since the nightly build currently breaks the scripts. I am no longer recommending nightly builds.

Thanks.

[vitorgalvao]

Even though we don’t yet have rules for when it’s acceptable or not to rename CLI tools (we do have them for GUI apps), users and contributors generally seem to care about and like this type of “normalisation” for CLI tools, so it was done with that in mind.

Having the scripts break on interoperability due to such a preventable change on our side would, naturally, be unacceptable, so those modifications were already corrected and merged, including using the stable version of handbrake-cli.

[lisamelton]

Cool! Thanks for the quick response and update. That's awesome. :)

I'll write a draft of the update to the README here so you can comment before I submit it. But it'll have to wait until I'm back home to do a test install. Probably later tonight.

If you want to write any draft yourself, feel free to do so. You're the expert on how it works.

Thanks again!

[lisamelton]

Oh, obviously I'll leave this issue open while we work on this.

[lisamelton]

Vítor,

Sorry, I got sick yesterday evening so I didn't work on this last night. I'm still sick but I'm trying to look at this now.

I just noticed a problem with the ffmpeg dependency. A few weeks ago, the maintainers of the ffmpeg formula for Homebrew decided to change the default options to avoid some licensing issues when building it as a bottle. That meant they disabled both AAC encoders. And this broke convert-video.sh.

A few days ago, I updated my README file to explain that when installing ffmpeg you now have to do this:

brew install --with-faac --with-fdk-aac ffmpeg

Is it possible to add this to your formula?

[vitorgalvao]

Please Don, screw software, health first¹; look at this at your convenience. Unfortunately we don’t have the option to provide install flags to homebrew dependencies, no, but I’ve already opened an issue so we can work on it.

If you want to close the issue in the meantime (since I can’t give a time frame for implementation), please feel free to do so (lingering issues can be annoying), as I’m confident I won’t forget to report back when we have a resolution (or an impossibility).

---

¹ Unless said software improves health, I guess.

[lisamelton]

Love that footnote. :)

And thanks for opening that issue! I didn't realize that wasn't possible yet.

The good news is that convert-video.sh still works correctly in the common case without those AAC encoders in ffmpeg. The bad news is that I found out about it from multiple users who are obviously applying that script in uncommon ways. Oh well.

I'll leave this open for now as I plan to get back to this in a few days, depending upon recovery time and how long it takes me to complete version 5.4 of transcode-video.sh which I stupidly promised to people by this weekend.

BTW, to document this correctly, I think I may need to reverse the order of the "Requirements" and "Installation" sections of the README. Or maybe even combine them. Not sure yet.

[edalzell]

As one of the folks on Twitter asking about this, thank you!!

[lisamelton]

BTW, I'm still working on this. I just don't like anything I've written so far. I'm now trying to merge the "Requirements" and "Installation" sections and then create sub-sections for manual and then assisted installation via Homebrew.

[JMoVS]

any news on this and availability via homebrew?

[vitorgalvao]

@daDnaK To be clear, they are already available, this issue is solely about the documentation.

You can get them all via homebrew-cask with brew cask install convert-video detect-crop query-handbrake-log transcode-video.

[JMoVS]

ah cool, thx. Worked as expected!

[vitorgalvao]

Closing this, since the new version is encouraged. Will also be removing these from homebrew-cask, so users don’t install them by mistake (and then open bug reports for unrelated versions).

Thank you for the continued work on these, Don.

[edalzell]

Why not add the new version to cask?

[lisamelton]

Vitor,

You are very welcome, sir!

Erin,

Since the new version is a Gem, I don't think a Cask is necessary for the tools themselves. But it might be handy to create a Cask of the dependencies.

[JMoVS]

So what is now the recommended way to keep these tools updated? Would it be possible to install this via homebrew and keep it updated that way?

Am 06.05.2015 um 20:50 schrieb Don Melton [email protected]:

Vitor,

You are very welcome, sir!

Erin,

Since the new version is a Gem, I don't think a Cask is necessary for the tools themselves. But it might be handy to create a Cask of the dependencies.

—
Reply to this email directly or view it on GitHub #8 (comment).

[lisamelton]

The recommended way to keep the tools updated is simply to update your installed Ruby Gems:

gem update

[JMoVS]

ah cool! Perfect, thx!

[edalzell]

sigh, Yet Another Package Manager. But I hear you Don, thanks for the great work you've done.

[vitorgalvao]

@edalzell As Don said, homebrew-cask would not add much by adding the new version there. In fact, it could even be harmful, were it to become outdated.

sigh, Yet Another Package Manager.

Yes, but that one is already installed by default.

As for

But it might be handy to create a Cask of the dependencies.

We actually started discussing that idea a while back, the concept of metacasks, but nothing as come of it yet. There is, however, a solution officially supported by homebrew, homebrew-bundle, that could be used for this. If it supported Brewfiles (files that describe what to install) loaded via a url (it does not) then one could be officially supported and a single command given to take care of all dependencies.

[lisamelton]

@vitorgalvao That home-brew-bundle idea is promising. Dang. Wish it had all those features. Especially since I simplified the dependencies for the Ruby version, e.g. FFmpeg doesn't require a special build anymore.

[vitorgalvao]

FFmpeg doesn't require a special build anymore.

I noticed that, it was pleasant to see. Always great when there’s one less thing to worry about.

That home-brew-bundle idea is promising. Dang. Wish it had all those features.

It does have a --file flag to use a specific file (instead of the one in the current directory, which is what it does by default), so in theory there could be a “curl this file and then brew bundle it” command, but that’s really ugly: two long commands with command flags, urls, and file locations. The commands currently in the requirements section are definitely more elegant: even if being six, they’re short, easy to understand, and outright look good in the flow of the document.