Create corresponding binaries for JetBrains IDEs

[yurikoles]

There is an option in JetBrains IDEs to create command-line palette, just like subl in sublime-text* formulas. If you create it manually from within the IDE and update it with brew cask install rubymine, it launches old one. After launching of brew cask cleanup, it obviously fails to launch.

[vitorgalvao]

@sebroeder Could you please advise here on the feasibility/official availability of this?

[sebroeder]

There are a couple of related issues here:

1. Should we install the command line helper by default for Jetbrains IDEs that support it?

Since the IDE has a guided first run setup that offers to install the helper anyway I opted for not installing it by default and let the user decide for herself, but I have no strong opinion on this and could change it cask to install the helper.

2. Should we uninstall the command line helper with brew cask zap?

I put /usr/local/bin/mine in the zap stanza e.g. for rubymine-bundled-jdk in #938 but the rubymine cask in homebrew-cask does not have it yet. As a user I would expect brew cask zap to clean up as good as possible.

@yurikoles you could install the rubymine-bundled-jdk cask from caskroom/homebrew-versions. This cask will cleanly uninstall /usr/local/bin/mine with brew cask zap rubymine-bundled-jdk. Is this the behaviour you want?

3. Corner case: There are problems when a stable release and a EAP release are installed at the same time

Since one can install a stable release and a EAP (early access) release at the same time (say RubyMine and RubyMine EAP) but both use the same path for the helper, things get messy. There is no way I can think of to handle this sutuation correctly in all cases (that’s the reason I did not want to automatically install the helper in the first place and let the user decide). This is a corner case though and may not affect may users.

Should I change the default behaviour for the casks in #938?

[vitorgalvao]

Should we install the command line helper by default for Jetbrains IDEs that support it?

Yes, if it is something expected, as in something most users will do (which is probably the case, here) and it’s something recommended by the vendor (also seems to be the case).

Should we uninstall the command line helper with brew cask zap?

No, but there’s a bit more to it. To install it, we should use binary. What that allows is for it to be set to a custom location (if the user sets it) and also gives us uninstallation for free.

I put /usr/local/bin/mine in the zap stanza

That should not happen, and that PR should not have been merged with that. As stated before, that should have been installed with binary, but even in a case where it wasn’t, that removal belongs in uninstall (since it’s part of the app), not zap (since it is not a preference).

The conflict you mention is indeed a problem, but it seems from your report it also happens when doing it manually, so it’s an upstream issue, and unrelated to our installation.

[sebroeder]

@vitorgalvao thanks for the clarifications, I’ll look into it.

[yurikoles]

But there is an issue with upgrdaes. If user creates this binary from app and then upgrades it via brew install, but binary points to previous path.

[vitorgalvao]

Using brew install --force to upgrade is a hack, either way. That should be handled when upgrade is introduced, not with workarounds.

[yurikoles]

I have not said anything about --force, I mean when app have been updated, it will have new path. I know what I'm tolking about, I have experienced this many times.

[vitorgalvao]

I doesn’t matter. Either using --force or not, installing on top of another installation to update is not the way to go; upgrade, when it is available, is. Why should we build a workaround for something you’re not supposed to do, instead of working on the real feature? There is no issue with upgrades, because upgrades aren’t supported yet.

I also ask that you check your attitude. We’re all volunteers, here, and you repeatedly comment with a sense of entitlement as if someone owes you feature additions. We don’t. I have given you the benefit of the doubt many times, but there are limits. This project isn’t about satisfying your specific needs, it’s about making it better for the community.

[arcreative]

Maybe it would just be easier to add it to the caveats? Something like the following:

On upgrade, the mine command may point to a previous version of RubyMine. To fix this, click Tools > Create Command-Line Launcher... from within RubyMine to update the binary to the upgraded version.

[arcreative]

Since the vendor has made it part of their setup workflow instead of part of the installation, it seems like it should be kept that way to avoid future breaking changes. It doesn't really seem like a nuisance as long as you know how to fix it. Then again, having it be automatic would be nice, as long as RubyMine can properly recognize that the mine command already exists on startup and doesn't try to replace it.

[adidalal]

Based on the discussion in #15876, we'll leave creating binaries to the app itself, otherwise we get into messy-hack territory, at least until #13201 is implemented.