Add a way to have overridden dependencies versions checked.

[sigurdm]

dependency_overrides have two main use cases:

• (A) One of your dependencies constrain another dependency too much, and you need to force a version to make resolution go through.
• (B) You want to obtain a dependency from another source than other dependencies expect it to come from (eg. using a local version of a dependency while developing a package).

Currently if you override a dependency, you are overriding both the version and the source. Thus, the version constraints on the dependency override are not validated.

For example in https://dart-review.googlesource.com/c/sdk/+/397164 we are trying to migrate the sdk to be a pub workspace. And all third party dependencies are overridden as path dependencies.
Ideally we would like that all version constraints on the third party packages would be validated, to prevent publishing new versions of the sdk packages with bad constraints.

I suggest this could be done by specifying a key next to the source description, something like:

dependency_overrides:
   foo:
     path: third_party/foo
     validate_version: true

We could also make it the default - but I'm afraid that would be too breaking.

@jonasfj WDYT?

[jonasfj]

I think dependency_overrides is aimed at (A).

I would guess that (B) is just something that people happen to use dependency_overrides for, but not what the feature is intended to solve.

Adding something like validate_version feels a bit bolted on. If we start augmenting source descriptions with things that aren't source descriptions, don't we risk more inconsistencies.

Suddenly, values under dependencies and dependencies_overrides have a different shape.

---

I'm not sure here, but I think we should be asking:

• (1) Do really want this feature? (version validation when obtaining a dependency from a different source).
• (2) Could this be done with another mechanism? (I'm not sure this is better, just asking the question).

I imagine that (2) could be:

dependency_sources:
  foo:
    - path: third_party/foo
    - path: first_party/foo

I'm not sure I like this idea either, because we generally embed identity in the location of a package. So it doesn't really make sense to say that foo can be foo from two differnet path-dependencies. When foo is a hosted dependency.

[sigurdm]

If we start augmenting source descriptions with things that aren't source descriptions, don't we risk more inconsistencies.

What we currently call the "description" is what comes after the source-name. So in

dependencies:
  foo:
    path: path/to/foo
    version: ^2.1.0

'path/to/foo' is the description, but the version constraint is not part of the description.

You might still be right, and it is desirable to have the dependencies and dependency_overrides sections have the same properties - not sure exactly why, but it feels meaningful.

And yeah, maybe it would make sense to split dependency_overrides in two separate fields, one for overriding the source(+description) and one for overriding the version constraint.

Trouble is that the current dependency_overrides already does both - so if we want to preserve backwards compat, we might end up with a weird hodge-podge.

[sigurdm]

(1) Do really want this feature? (version validation when obtaining a dependency from a different source).

I think this makes a lot of sense in the for the SDK where we want to override the source of the dependencies we build against. But you might be right that it is less useful in general.

[sigurdm]

If we land https://github.com/dart-lang/pub/pull/4427 I think it makes a lot of sense to override some dependency to come from git, but still have all version constraints on that package respected.

See also #4496 that (as I read it) complains that it is surprising that using a non-hosted source in the root doesn't change the source everywhere.