Feature request: XOR with depends_on

[mathewpeterson]

Description of feature/enhancement

It would be nice to have the ability to define an exclusive or with depends_on. For example, Only one of the two dependencies are required but not both.

Justification

There is at least one package that has a hard dependency set for but doesn't actually need it if another (undefined) dependency was met.

Example use case

The dockertoolbox cask has a dependency on virtualbox cask. I believe this is because Kitematic defines a dependency against Virtualbox, even though it's possible to use VMWare.

In order for me to use brew to update the dockertoolbox package, I have to remove/comment out the depends_on cask: 'virtualbox' and then update the package.

Please let me know if there is any other information I can provide.

[adidalal]

The linked issue says it only kind of works, upon a very quick skim - is there any official documentation to the contrary?

(That being said, I'm not opposed to the feature request, just wanted more info about docker+vmware)

[mathewpeterson]

Yes, you are correct. However Kitematic is only one of the many tools inside the Docker Toolbox.

But since Docker has standardized installing everything via Docker Toolbox and I don't use Kitematic, it would be nice to not have to deal with this issue every time there is an update.

I apologize if I am not making much sense.

[vitorgalvao]

Not sure this is something we want to handle. It’s not a big problem, and its severity will only decrease, so I doubt it’s worthwhile.

[adidalal]

FYI dockertoolbox isn't on that list - but I agree, it's a minor problem.

PRs to add said functionality are of course welcome.

(Closing, just to keep things tidy. Feel free to reopen if more appropriate)

[mathewpeterson]

@vitorgalvao Why do you say that it's severity will decrease? Are you suggesting that Docker toolbox cask will eventually be removed and we will install the components individually?

I am also open to any other suggestions on how to disable the dependency. It's just very inconvenient to have to manually edit the cask every time I want to update.

[vitorgalvao]

Why do you say that it's severity will decrease? Are you suggesting that Docker toolbox cask will eventually be removed and we will install the components individually?

Not talking about docker toolbox specifically (although it also applies) but about any cask in this situation. Casks that have dependencies are usually specific cases, and many of those are better suited as formulas anyway. Point being there are so few casks (and getting fewer) that would benefit from a xor depends_on, implementing it wouldn’t be worth it.

As @adidalal mentioned, PRs are welcome, but this is something we don’t really want to pursue.

[mathewpeterson]

I am still having a difficult time understanding how this won't be a problem in the future.

Casks that have dependencies are usually specific cases, and many of those are better suited as formulas anyway.

Are you suggesting that this cask should be replaced with a formula to run the installer? If that is the case then can you please provide an example of a Brew Formula that runs an installer rather than building something from source?

I understand that this specific use case isn't something that find valuable so I'm just trying to figure out a better work around.

[vitorgalvao]

No, what I am saying is that if we only have 2 casks out of 3000 that would benefit from a feature, than naturally implementing that feature is very low on the list of priorities.

Right now, it would be so low it’s not even worth considering. However, we will entertain a PR if someone wants to work on it.