Refactor the registry system

[mara-schulke]

Current State

At the moment users specify registries and repositories in every single dependency declaration. This does not only lead to a chunky Proto.toml as we repeat common information way more often that we actually need to, it also has a semantic impact:

It allows users to request a dependencies from distributed registries at the same time and it inherently teaches buffrs about the existence of repositories.

E.g.

[dependencies]
foo = { registry = "https://foo.bar/baz", repository = "bar", version = "=1.0.0" }

Context

In the realm of dynamic version resolution we need to rethink this current state: Established version resolution algorithms like pubgrub and resolve are not aware of this situation.

E.g. in the current situation a package a@1.0.1 could be present in the repository foo and a@1.0.2 could be present in the repository baz. When using the above mentioned version solvers with a request to install a>=1.0 this leads to a quite hard decision problem: Do we want to jump repositories when we know that there is a later stable release present in another one? How do we get to know about the other repository? Is this the desired behavior?

Although this setup may seem odd at first glance it is not so far of some real world setups using artifactory where repositories are used to distinguish between stability. E.g. many companies publish prereleases and stable releases into different repositories.

A possible way forward

Some possible ideas to solve this problem are:

Using Named Registries

Using named registries we can move towards a registry based approach and drop our in-manifest knowledge about repositories altogether.

Users could name registries in a configuration file and declare a set of artifactory repositories to search through:

$HOME/.buffrs/config.toml / $PWD/.buffrs/config.toml:

[registry]
default = { uri = "http://foo.bar/baz", repositories = ["a", "b", "c"] }

When installing buffrs would now search the above repositories (using the artifactory search api) to locate possible releases. This would be quite efficient and elegant as this would result in the manifest looking like this:

[dependency]
foo = "=1.0.0"

or (foo = { version = "=1.0.0" }). Which is not only much more readable but also leaves us the ability to jump around repositories within the same registry to resolve different versions, thus unifying the version set from being sharded across repositories into one big searchable version set for version resolution. All of this is achieved while stripping out the repository concept from the actual buffrs manifests!

One caveat is that we need to still specify the exact repository when publishing, but this can be done via the cli anyway.

Dropping prereleases

See pubgrubs take on prereleases. They introduce a lot of headache when trying to do version resolution correctly and it may be a good tradeoff to drop their support for now in order to ship proper dependency resolution.

---

I am probably not going to have the time to finish this any time soon, contributions are welcome.