This makes good on #28 and #29.

I removed some of the .PHONY targets from your Makefile. I don't really know what those do, either... 😅 If you have any links handy, that'd be great!

TODO

• [ ] Get make check passing
• [ ] Decide which version of CMake to use/install for CI
• [ ] Decide which version of CMake to set as the project minimum
• [ ] Get CI builds working
• [ ] Review for parity with previous Makefile
• [x] Test that header changes cause rebuilds (#28)
• [ ] Test that tests can be built in parallel (#29)

#45 and #46 will be easier if users are able to reconstitute a fully resolved dependency graph and pass it into Arbiter, instead of just consuming them. To do that, we basically move all of the DependencyGraph API which was only in Resolver.cpp into the public interface, and move the previous "install-ordered graph" logic into a more properly named ArbiterResolvedDependencyInstaller type.

To do:

• [x] Update bindings

Priority is used to determine which requirements are eligible for intersection. Requirements in two different priority bands will never be intersected.

This can be used to implement unpinned versions like a branch or commit hash, by creating a requirement which is higher priority (a lower numeric index) than the default.

cc @mdiep

I suggest to reuse a higher level build system than your current small make file so that powerful checks for software features will become easier.

• CMake
• Autotools

This is useful to match upon and provide versions using only metadata, part of implementing "unpinned" versions (like picking a branch).

cc @mdiep

From the SemVer spec (emphasis mine):

… identifiers consisting of only digits are compared numerically and identifiers with letters or hyphens are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence than non-numeric identifiers. A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

std::future composes so poorly that it's amazing it even made it into the standard. It basically requires that any user block while work is performed.

We should write something similar which allows a callback to be invoked instead.

For some kinds of clients, like package managers for system binaries, uninstalling a package is a very common use case. However, unless the package manager knows which other packages depend upon it, this can be a very unsafe operation.

We should offer hooks for recording the complete dependency trees associated with each installation. The client would be expected to provide storage and lookup, but could avoid reinventing our dependency tracking as long as we hand over all the necessary information.

Once building is part of the Arbiter API, we could offer some generalized hooks that support looking up and reusing cached builds (instead of repeating a build from scratch).

For example, Carthage supports downloading pre-built frameworks uploaded with GitHub releases.

We probably don't need to get that specific, but we can add a generic API that allows the Arbiter client to install a cached build before we actually trigger our build step.

After dependencies are checked out, there will usually be a build step. This would be where compilation occurs (for clients where it's relevant), or post-processing like Babel, etc.

The main advantages of building this into Arbiter are:

• We already have information about the ordering of dependencies, and can apply this to the build (i.e., build all dependencies before the dependent)
• We can interleave/parallelize building with the rest of dependency resolution, since there are points at which we know that certain dependencies are "locked in"

For example, this API should support constraints such as "compatible with 1.2", and allow checking them against specific versions (e.g., 1.2.3, which should be compatible).

We could use the Carthage API for inspiration.

Travis should be able to automatically regenerate our Doxygen docs, which we then push… somehow. Might need a separate gh-pages branch for this purpose.

Right now, we have a lot of occurrences of, e.g., std::shared_ptr<ArbiterRequirement> which could instead be std::shared_ptr<const ArbiterRequirement>.

Yesterday, Facebook announced a new package manager for JavaScript called Yarn.

Yarn is a collaboration between Facebook, Exponent, Google, and Tilde.

It's early days but once the Node bindings (and underlying core lib) are more mature it could be worth trying this.

🚧 WORK IN PROGRESS 🚧

To do:

• [x] Refactor resolution algorithm to be iterative? (Might make backmarking, etc. easier)
• [x] Refactor ArbiterResolvedDependencyGraph to be a simple value type, and not store requirements
• [ ] Figure out what to do for branch/commit pins ("unversioned" requirements)
• [ ] Restore incremental resolution functionality
• [x] Restore statistics about dependency resolution

Future work:

• Backmarking/culprit variables
• Offer a mode where we try dependencies with the most constrained first—this means that ordering isn't deterministic over time, which is why it should be optional, but it should be more efficient if it eliminates more of the search space