CODEWITHSUNDEEP
dartconstraintsincompatibilitydart-pub
Cristian Garcia
Cristian Garcia

Reputation: 9859

Pub Error: Incompatible version constraints on analyzer

I have a very weird problem. I have some dependencies that previous to adding a new dependency work well, but as soon as I add a new one (in this specific case async_await) I get an Incompatible version constraints on analyzer error when using pub get. The curious thing is: async_await is NOT an incompatible constraint!

Pub get failed, [1] Resolving dependencies... Incompatible version
constraints on analyzer:
- angular 1.0.0 depends on version >=0.15.0 <0.19.0
- di 3.3.1 depends on version >=0.15.0 <0.22.0
- redstone_mapper 0.1.1 depends on version >=0.13.0 <0.14.0

Why doesn't this error show when I remove async_await (this same thing happened with another import) if the constraints should still fail?

Update

Running pub upgrade reveals another problem

Resolving dependencies...
Incompatible version constraints on analyzer:
- angular 1.0.0 depends on version >=0.15.0 <0.19.0
- async_await 0.0.0 depends on version >=0.22.4 <0.23.0

Pubspec.yaml

name: aristadart
description: A sample web application
dependencies:
  angular: 1.0.0
  browser: any
  di: any
  fp: any
  http: any
  mongo_dart: any
  redstone: any
  redstone_mapper: any
  redstone_mapper_mongo: any
  shelf_static: any


transformers:
- redstone_mapper
- angular:
    html_files:
    - lib/components/login/login.html
    - lib/components/login/nuevo_usuario.html
    - lib/components/home/home.html
    - lib/components/evento/evento.html
    - lib/components/vista/vista.html

Upvotes: 5

Views: 15169

Answers (2)

munificent
munificent

Reputation: 12364

Pub's version solver is doing a global analysis of all of the version constraints in all of your dependencies. Not just that, but each version of a dependency has different constraints.

This means constraint failures can be non-local. It's not just that async_await has a constraint that causes a problem. It could be that:

  • async_await adds a constraint on foo.
  • That forces you to take a different version of foo than you would otherwise.
  • That in turn gives you a different set of constraints coming from foo.
  • Those in turn tweak some of the versions of other dependencies.
  • Which then lead to other different constraints...
  • And so on...

In practice, most of the errors like this we've seen recently seem to have the analyzer package as their lynchpin. The analyzer folks rev that package really frequently (or at least did for a while) and change its minor version often. That means there are a lot of packages that depend on disjoint sets of analyzer versions.

Like @Günter suggests, the workaround is to override a couple of dependencies, so that can cause its own problems. (It basically turns a "pub get time" failure into a possible runtime failure.)

Upvotes: 5

G&#252;nter Z&#246;chbauer
G&#252;nter Z&#246;chbauer

Reputation: 657018

There is just no set of dependencies where all version constraints fit.
I solve such problems by pinpointing the version of some dependencies to make the life easier for pub get/pub upgrade and add some dependency_overrides to force-solve some discrepancies.
Add overrides one by one until no more errors occur.

In your case I had to add quite a few overrides

dependency_overrides:
  analyzer: ^0.22.4
  barback: ^0.15.2+2
  code_transformers: ^0.2.3+2
  di: ^3.3.3
  route_hierarchical: ^0.6.1

This way you force packages to use dependencies they are not tested with but it's the only way to solve it (besides updating the dependencies itself to use newer versions, but this is usually controlled by others).

Upvotes: 8

Related Questions