Version resolving for vcs hosted packages

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.

Feature Request

TL;DR I'd like to be able to resolve vcs hosted package versions just like PyPI hosted packages.

Consider the following package structure:

A (vcs hosted)
|-- B (vcs hosted)
|   `-- C ref=1.0.0 points to v1.0.0 (vcs hosted)
`-- C ref=1.1.0 points to v1.1.0 (vcs hosted)

If those packages would not be vcs hosted we could say in both A and B's requirements that C should be at version ^1, so we'd end up with the latest version, say v1.1.0. However, because these are hosted on a vcs, we currently end up with an error, because both references to C should, but don't, refer to the same ref.

My suggestion would be to be able to add a version property to vcs hosted packages, so we'd get for instance

C = {git = "ssh://git@github.com/someone/C.git", ref = "1.1.0", version = "^1"}

When the version property is given, we should treat this like a normal package, look at what version the package itself communicates, and use the latest compatible one. So in case of the example:

• B requires C ^1, and provides a candidate using a link to C ref 1.0.0, which is at version 1.0.0
• A requires C ^1, and provides a candidate using a link to C ref 1.1.0, which is at version 1.1.0

We could say we'll take C ref 1.1.0, because it provides the latest version.

In order to save the trouble and speed bump of cloning the repo to see what version it provides one also could require that the tag is equal to the version number, an that the ref is a ref to the tag, so in the example above, ref 1.0.0 and ref 1.1.0 are refs to tags that can directly be used as version numbers.

Alternatives

Using branches

An alternative that already works would be to create a branch 1 and use the following:

C = {git = "ssh://git@github.com/someone/C.git", branch = "1"}

This gives the overhead of maintaining an extra branch in a vcs, and it looses the control over the requirement of a version range smaller than the major version, e.g. version = ">=1.1,<1.3" is not a thing, as it simulates version = "^1".
This could be overcome by adding a branch that does precisely that, but I think you the point by now.

Private PyPI

An other alternative is maintaining a private PyPI. I think that's a quite fat solution for a problem that could be so small.

Start by tracing Poetry's dependency resolution path for VCS-hosted packages and the handling of git and ref requirements. Define how a VCS dependency with a version constraint should produce and compare candidates, then verify that the example with C refs 1.0.0 and 1.1.0 selects the compatible latest version without breaking existing branch or VCS behavior.