Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: OR or XOR switches for depends_on stanzas #26345

Closed
BenjaminHCCarr opened this issue Nov 2, 2016 · 5 comments
Closed

Feature request: OR or XOR switches for depends_on stanzas #26345

BenjaminHCCarr opened this issue Nov 2, 2016 · 5 comments
Labels
awaiting maintainer feedback Issue needs response from a maintainer. core Issue with Homebrew itself rather than with a specific cask. enhancement

Comments

@BenjaminHCCarr
Copy link
Contributor

BenjaminHCCarr commented Nov 2, 2016

Description of feature/enhancement

Justification

There are casks that can work with multiple casks or brewed formulas which provide the same functionality and often the same named binary. This came up a very long time ago with #2001; and I am even going to use sshfs as the example.

Homebrew allows for arrays and switched , but the only array I can find in the docs:
https://github.com/caskroom/homebrew-cask/tree/master/doc
is for depends_on macos: ['10.9', '10.10’]

I can't seem to find any other arrays or switches.

Really I think the depends_on should be some sort of pseudocode like:
depends_on: [formula: 'homebrew/science/r', cask: 'r-gui']

or

depends on{
   formula: 'homebrew/science/r'
   OR
   cask: 'r-gui'
}

I just updated #26340, so r is on my mind.

is this functionality implemented but not documented; eg, am I missing something?

Example use case

The example given at depends_on doc is sshfs which could depend (until very recently) on osxfuse or Fuse4x and their are other places where someone may choose a binary/cask rather than a formula. I know this has been discussed.

Similar issues:

--flags on formula #8784
depends_on :cask follow-ups #8492
using depends_on for intra-Cask dependencies and metapackages #2001
Feature request: XOR with depends_on #19369

Possible solution condition statement or array:

The real crux is very similar to (though not NEARLY as complicated as):
Stanzas in conditional statements #14333

In the example of the package I bumped today r-studio #26340; /applications/R.app is not an option in homebrew/science/r as there is no --with-bundle flag, so many choose to install bothhomebrew/science/r-gui as well; note, these do NOT conflict; though r-gui makes brew doctor very very upset. However both provide a "functional" r binary. With the way I see stanza depends_on: is written now; I had to use depends_on formula: 'homebrew/science/r'

Is there an undocumented way to use conditionals with depends_on:? I tried some hacks with ==> and arrays [..,..] but thought merging to get everyone to stable (no less 1.0 finally) was worth more than me blindly throwing similar conditionals at the formula.

So my proposed solution would be something like we use for depends_on macos: or a ruby OR

Change depends_on to be something like this pseudocode:

depends_on: [formula: 'homebrew/science/r', cask: 'r-gui']
or

depends on:{
   formula: 'homebrew/science/r'
   OR
   cask: 'r-gui'
}

Since the first is already implemented for depends_on macos: I think it would be the path of least resistance to implementation while also not break anything currently written, and making the tests just check for what they already do on the os stanza.

@vitorgalvao vitorgalvao added enhancement awaiting maintainer feedback Issue needs response from a maintainer. core Issue with Homebrew itself rather than with a specific cask. labels Nov 2, 2016
@vitorgalvao
Copy link
Member

vitorgalvao commented Nov 2, 2016

depends_on: [formula: 'homebrew/science/r', cask: 'r-gui']

To me, that reads like “and”, not “or”.

Your other suggestion I find confusing, and you’re right the first one is closer to what we get, so it makes more sense.

I have no objection to this feature (even if the syntax needs further thought), but I would also put it as very low priority. It’s not very common for this case to happen, so I question the validity of spending time on it.

Thank you for the detailed feature request, either way we end up deciding.

@BenjaminHCCarr
Copy link
Contributor Author

BenjaminHCCarr commented Nov 2, 2016

It was just a pass (and why I had the commnt about requiring an r in #26340 in the first place. This was just me getting it down while it was on my ming and calling it 'pseudocode'.

The first is just a 'stanza' translation from: depends_on macos: at https://github.com/caskroom/homebrew-cask/blob/master/doc/cask_language_reference/stanzas/depends_on.md to depends_on: general where the options listed for macos are:

depends_on macos: [:mavericks, :yosemite]
depends_on macos: ['10.9', '10.10']

I can see that looking like logical "and" but it is implemented as logical "or" for macos.

The other/second was an "attempt" at being less obtuse/more explicit in what was going on that one was a cask and the other a formula.

@BenjaminHCCarr
Copy link
Contributor Author

So, I'm going to dredge this up as the db-forking seems to be causing problems:
As was noted in Homebrew/brew#1887 the my/maria/others seems to be more than a doctor problem.
ntopng --with-mariadb fails to upgrade/reinstall @3.0 : Homebrew/homebrew-core#14278

and while the problem is likely actually unrelated unless mysql ships with it's own libiconv.dylib it brought me back to thinking it was a DB problem with the --with-mariadb as until reinstall it just fails, I wasn't even able to get it to gist.

@MikeMcQuaid
Copy link
Member

We already have a solution to this problem: Requirements i.e. depends_on :foo (the colon). This will allow you to add to the PATH any directory, add anything to the ENV and depend on any formula at compile-time. This is all the surface we wish to support but we're open to adding more requirements when they make sense.

@vitorgalvao
Copy link
Member

This isn’t problematic enough (very few casks would benefit) and there seems to be not enough interest in implementing this, so closing as part of issues cleanup.

@lock lock bot added the outdated label Jan 15, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jan 15, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
awaiting maintainer feedback Issue needs response from a maintainer. core Issue with Homebrew itself rather than with a specific cask. enhancement
Projects
None yet
Development

No branches or pull requests

3 participants