Add support for Xcode plug-ins artifact

[norio-nomura]

Add xcplugin stanza.
I want to use Homebrew-Cask for managing Xcode plugins. (as alternate of Alcatraz.)

[jawshooah]

Why not use Alcatraz? I don't want us to start creating DSL extensions for package formats that already have dedicated package managers.

[alebcay]

Shameless Plug™: If you wanted to have scriptable Alcatraz usage, check out my project alc (not really under active development, but still functions fine). Useful for provisioning scripts, etc. You may find that it offers the CLI-ness that you're looking for in Homebrew Cask.

[norio-nomura]

Why not use Alcatraz?

Because Alcatraz is a Xcode plug-in itself.
When Xcode is updated and Alcatraz becomes incompatible with updated Xcode, it needs re-installing by installer script of Alcatraz.

[jawshooah]

Then wouldn't it be better to just add a cask for Alcatraz itself? You said it uses an installer script, so we don't need to add any new DSL.

I worry that if we go down this road, we open ourselves up to accepting casks for Ruby gems, Python eggs, Sublime Text and Atom plugins, etc.

[norio-nomura]

I worry that if we go down this road, we open ourselves up to accepting casks for Ruby gems, Python eggs, Sublime Text and Atom plugins, etc.

As far as I know, Alcatraz is not reliable as comparable to them. I can understand your worrying.
Hm, perhaps It would be better creating .pkg for installing my .xcplugin and use it from Cask.

[vitorgalvao]

I worry that if we go down this road, we open ourselves up to accepting casks for Ruby gems, Python eggs, Sublime Text and Atom plugins, etc.

Exactly. We’d be crazy to do it. We’d be duplicating work and doing it worse than those package managers for their purposes. Not only would we be adding a ton of new casks we’d have to now manage as well, as soon as one of those didn’t work by installing with our methods, we’d need to start building workarounds for that in the core, and that is exactly what we’re fighting. I was even against the inclusion of fonts, to begin with.

Shortly after that, we got an issue requesting the ability to install operating systems! My answer there still very much applies. Too many things were said “yes” to at that time. I always opposed that way of operating, but the excitement of the community of the possibilities always overwhelmed those expressed concerns. The result is we have a ton of half-baked unimportant features (most of them without much of a real point, like licenses) and the ones who started them have since gone away to work on other things.

While managing the project, I very much intend to do the opposite. I understand the desire to have everything neatly packed in a single place, but we have very limited resources, and adding yet another cask type to duplicate functionality of installing packages, and having them become outdated, is even potentially harmless.

This is a simple addition to the core itself, though, and with the simplifications we have planned, this could be a “not yet, but perhaps we can discuss it again in the future”. Your contribution is also appreciated, and it was a fine PR, thank you. However, I’ll say “no” outright, and the reason is simple:

As far as I know, Alcatraz is not reliable as comparable to them.

Then the solution is clear: Alcatraz needs to be made better. Building a workaround via homebrew-cask is not the answer.

[norio-nomura]

Thanks for reply. Sorry for my thoughtless PR.
Thank you very much for your working on Homebrew-Cask.

[vitorgalvao]

Sorry for my thoughtless PR.

Not at all. It’s just a shame you had all that work that got discarded, but you having gone through it is appreciated, specially since it was a quality PR.