Add support for custom version requirements with a predicate

[jspahrsummers]

This enables support for requirements like "pin to this named branch," where maybe a semantic version isn't available.

[jspahrsummers]

@kastiglione @mdiep Can you please take a look at this and see if it makes any sense? The logic ended up a bit different from Carthage, because Arbiter doesn't inherently have knowledge of what kinds of versions should clobber others—instead, it can only check a version against each requirement.

[mdiep]

Ideal might be a better name here.

[mdiep]

Can you please take a look at this and see if it makes any sense? The logic ended up a bit different from Carthage, because Arbiter doesn't inherently have knowledge of what kinds of versions should clobber others—instead, it can only check a version against each requirement.

Makes sense to me. But I do think that's going to prevent you from optimizing by pruning nodes upfront.

[kastiglione]

Not to get caught up on naming, but I like the word "override", or something that communicates that this has been hand picked.

[kastiglione]

Makes sense, though that doesn't say much since my knowledge about the inner workings of Carthage, or dependency managers in general, pales compared to you two.

[mdiep]

The other thing to consider here is that Carthage has a bug currently where it loops endless in some cases because of these sort of overriding constraints with non-semantic-versions. Because they're compatible with everything, you can get into situations where a version is picked that doesn't meet your requirements, even though nothing explicitly selected that version.

[jspahrsummers]

Because they're compatible with everything, you can get into situations where a version is picked that doesn't meet your requirements, even though nothing explicitly selected that version.

I think this implementation would behave differently, because versions determined to be the "best" are not just compatible with everything—they override everything, and other versions get pruned from the graph.

That said, I'm not very happy with how this turned out, and given that neither of you were very gung-ho either, this probably deserves more thought. 😔

[mdiep]

I think Arbiter should be opinionated about how to handle non-semantic versions.

[jspahrsummers]

What should that mean here? It's hard to be opinionated when the library is this general. 😕

[mdiep]

I just suspect that there's 1 reasonable approach to versioning with unversioned dependencies (non-semantic tags, branches, commits, etc.). IMO Arbiter should implement that so there's 1 easy built-in way, even if it enables other approaches.