You can clone with
I'm running into a conflict between formulae with the same name in my tap, and in homebrew/science and mainline.
Toward the end of this issue, you will see that despite my julia formula depending on staticfloat/julia/openblas, the openblas from homebrew/science is getting installed.
@staticfloat is right and in the last few weeks this must have changed, because it worked before. Not sure which change is the cause though
This issue is a blocker for some third-party taps such as julia.
Just wanted to ping you all on this again, as it really is a problem for people wanting to install Julia. I can look into a fix on this if you can give me a starting place to look.
@jacknagel said, he is going to fix some things these days. Jack, if you are not about to tackle this, I could make a PR but I don't want to waste work on this if the depdens_on/requirements/options code is being reworked.
This is still causing users of my tap to have compilation problems, as mxcl/suite-sparse is getting installed instead of staticfloat/julia/suite-sparse.
@staticfloat how should this behave if I already have a brewed suite-sparse? Should it deinstall the other one?
Can we perhaps make the deps you need more appropriate to your needs.
Ideally, we would have options that we can require of the dependent suite-sparse formula. E.g. the only difference between staticfloat/julia/suite-sparse and mxcl/suite-sparse is the former adds TBB as an option, not included by default, and it uses OpenBLAS as its backing BLAS implementation, as opposed to Accelerate.
This will only be possible once #14456 lands though, as without it I cannot enforce dependencies with certain options.
What if two different formulae require a usera/foo/suite-sparse and userb/baz/suite-sparse resp.?
As @mxcl said elsewhere, it is a feature that depends_on 'foo' can be satisfied by suite-sparse from different taps (only one can be active at a given time).
So the current work-around would be to name your suite-sparse like suite-sparse-julia and make it keg_only.
When we can depend on a formula with a certain option set, we should try to use that assure a certain feature is enabled.
I would even go so far, to say the current implementation is better and with @jacknagel's work on deps with options, we can soon handle 95% of the cases why people would want that feature.
As said above, the current work-a-round is: Name it differently and keg_only it. Or better, submit a PR. I for example, am willing to make TBB the default for suite-sparse.
Once we have dependency options, we can work around this, as we can add an option to suite-sparse to omit TBB. (Right now, TBB is the default for suite-sparse, which is the problem for Julia)
I would submit a PR to fix this, but I'm not very good with Ruby, and have a hard time figuring out what's going on. The best I can tell, it's because by the time things get to install_dependency, the dependency has had the tap information stripped out of it, effectively destroying all use of the depends_on 'username/tap/formula' syntax. I'm not sure why the tap gets stripped out, though.
I'd like to see (if it's even possible) that two different versions explicitly depended on from different taps are both installable at once perhaps with different names/versions.
Mike, I am afraid, I don't get what you are wanting.
As in either have suite-sparse from the julia tap installed as suite-sparse-julia without manual renaming (if you specify the full dependency to the tap) or install it as version e.g. 1.0.0-julia.
I've gone ahead and done as you suggested @mikemcquaid, thank you.