Implement conflicts_with stanza

[jawshooah]

Closes #4497.

As mentioned in the commit message for 46738c9, most of conflicts_with.rb was taken directly from depends_on.rb and modified accordingly. It would be likely be better to outsource common methods to a shared superclass or utility class.

[phinze]

Do we support machines running PPC?

[jawshooah]

Seems we do.

[phinze]

Nice work on this so far @jawshooah - thank you! Left you plenty of review notes - happy to clarify and discuss any of 'em. 👍

[jawshooah]

Thanks for the speedy response! I love a good code review.

As noted in the opening comment, most of the changes here (including much of what you've commented on 😉) were taken directly from depends_on. When addressing your suggestions, should I make similar changes to that implementation as well?

[phinze]

When addressing your suggestions, should I make similar changes to that implementation as well?

If you're willing, that'd be great! Though I'd probably approach that as a separate "refactor depends_on" PR to keep things from getting too hefty.

[rolandwalker]

I recommend against this degree of duplication of code.

[jawshooah]

@rolandwalker Agreed, I'm just not entirely sure of the best way to go about deduplicating it. It seems like every class in Hbc::DSL is intended to map one-to-one with a DSL stanza, so I don't know if creating a Hbc::DSL::Dependency or similar superclass for ConflictsWith and DependsOn would be a breach of style or expectations. What do you think?

[jawshooah]

One obvious thing that would help would be to move self.coerce_os_release to Hbc::MacOS. #9329

[phinze]

Ah yeah I didn't see the amount of similarity this had with depends_on in my initial review. I think Hbc::DSL::Dependency as either a superclass or a mixin is a great idea.

[jawshooah]

@phinze I've moved all shared logic to Hbc::DSL::Dependency and Hbc::Dependencies.

The depends_on refactor is all in 6503dbc (build failure seems unrelated), so if desired I can leave that out and save it for another PR.

[jawshooah]

Turns out it wasn't so unrelated; the pairs method of DependsOn wasn't stubbed out in the tests that failed, and they were skipped on my machine. Pushed a fix, all tests should pass now.

[rolandwalker]

Procedurally:

While we are pretty darn good about writing roadmaps in this project, it is not practical to get 100% of our private branches, thoughts, and IRC discussions into GitHub issues. So, there are some things about implementing conflicts_with that haven't been outlined, about which, see below.

When the idea of implementing conflicts_with was mentioned in #9202, I responded by self-assigning #4497. As explained in #8784 (comment), that was a quick way of saying "Heads-up guys – working on this thingy is likely to involve wasted effort".

Substantively:

• conflicts_with and depends_on are conceptually and architecturally related. The features are being built out in a certain order, and conflicts_with was intentionally deferred.
• depends_on was fully separated from the old depends_on_formula in DSL: remove support for depends_on_formula #7401 so that we could make it general.
• Improvements and support for various new keys were added in a series of subsequent PRs (eg depends_on :macos in DSL: depends_on :macos #7696) – the easy cases.
• In Implement depends_on :cask #8491 and others, @ndr-qef made fixes, and added the harder case of depends on :cask, introducing a proper dependency graph.

Roughly, the path leading to conflicts_with was:

• factor dependency checking out of installer.rb
• generalize the dependency graph to include all depends_on keys (not just :cask), so that we can walk the graph and verify that all dependencies are installable before acting
• implement conflicts_with in terms of the dependency graph

Currently, the folks interested in dependencies are discussing whether to add interface to support pure meta-Casks (#8492). It is worth noting that there is a divergence of opinions about whether or not to support meta-Casks, and what the interface might be. The maintainers are responding to that by taking their time, being consultative, going to extra effort to collect opposite views. It's a tautology, but: the only way we can work together is by coordinating, asking questions, and listening.

Scanning this PR, conceptual flaws are apparent, such as the notion that one can serially satisfy_dependencies, satisfy_conflicts, or flatten/ignore the dependency graph in "conflict mode". Nor are impossible depends_on/conflicts_with combinations detected.

Furthermore, it is too large. depends_on was developed over at least a dozen PRs with ample space for discussion.

[phinze]

Ahhhh ok! Thanks for laying out the full context so clearly @rolandwalker. I was running behind on the overall conversation here, and I dove into line-by-line review before I should have. Sorry to steer you in the wrong direction @jawshooah!

Sounds like we're going to need to back up a little bit on this feature: resolve the direction in @rolandwalker's linked conversations, then break down the pieces so we can avoid any big-bang PRs.

Thanks for diving into this @jawshooah - once I'm a little more caught back up I promise I won't lead you waste work like this. 😕 We may not merge this work as is, but it definitely helps to inform the progression of the feature as a whole, so thanks for that! 👍

[jawshooah]

Thanks to @rolandwalker for context, clarification, and critique. @phinze, don't worry about it. I should have asked around more before diving headfirst into the implementation.

Is there currently an open discussion around implementing a more generalized dependency graph? It seems like resolution would proceed as follows:

• Create a graph with one node (the root cask) and no edges.
• Add a node for each dependency, and an edge directed from the source to its dependency.
• Recurse through dependencies until all edges have been created.
• Check for cycles, and fail if one is found.
• Check conflicts for each dependency and ensure that none are present in the graph or already installed.

Obviously this is going to take some deeper thinking, but that's the gist as I understand it.

We will need to interface with Homebrew to get formula dependencies and conflicts, the latter being inaccessible through the brew CLI, and the former limited to formula -> formula dependencies with brew deps --union formulae.

Homebrew also has a much longer list of dependency types. We may need to either restore some of homebrew-fork or write our own formula parser/loader to handle these.

We'll also need to hardcode in relationships between arch, macos, x11, and java.

This is going to be quite an endeavor.

[rolandwalker]

We will need to interface with Homebrew to get formula dependencies and conflicts,

Very nice catch! I intentionally deleted that bullet point, in order not to muddy the waters, and added the weasel-word "roughly" to cover my behind. It is probably best not to try to resolve Formula dependencies, and just pretend that it works until we encounter breakage. It's too much work!

depends_on is not fully born yet. Bringing it the rest of the way into the world is not a terribly forbidding endeavor. Or shouldn't be.

And then, if depends_on is expressed well in code, conflicts_with should fall out fairly naturally as an inverse-dependency. There are other package managers whose code we could consult if for some reason we got stuck.

Almost nothing is "expressed well" at the moment, because of the transition phase of #4688. In large part, git history would show that I took @phinze's designs and subjected them to … bending and denting.

It's a design lesson! Good design will survive the next guy.

[jawshooah]

Ignoring Formula dependencies makes me feel queasy, but it probably won't cause many problems in practice, and I agree that the effort required to handle them properly is probably too much, at least for an initial implementation.

Though this first attempt was a bust, I'm still very eager to contribute! Is there any way that I can help to bring proper dependency resolution to fruition? I don't want to step on any toes, but there must be something I can hack away at.

I care a lot about this project, and I'm happy to lend a hand wherever needed.

[jawshooah]

@rolandwalker Is anyone currently working on a more comprehensive solution for dependency resolution as you described? I wasn't sure whether your response to this PR was an invitation to give it another, better-conceived shot or a polite request to let the big boys handle this one 😉