Unhelpful error messages in case of package version conflicts

[dgreensp]

When the version solver can't resolve the dependencies of the project while satisfying all the constraints, it prints a message that doesn't necessarily indicate where the problem is.

A particular case of this is #3351.

Post your repros here.

[mquandalle]

Hello David,

I encounter the following error message:

While selecting package versions:
error: conflict: constraints on underscore cannot be satisfied.
Constraints come from:
<top level>
mquandalle:autofocus@0.2.0
mquandalle:autofocus@0.2.0 -> meteor@1.1.4

Maybe it's just me, but this message does not really help me solving the conflict. It may be related to the fact that I'm trying to rely on a release candidate version of meteor:

Package.onUse(function(api) {
  api.versionsFrom('1.0.4-rc.3');
  api.use('blaze');
  api.use('templating');
  api.use('underscore');
  api.addFiles('autofocus.js', 'client');
  api.export('AutofocusableTags', 'client', { testOnly: true });
});

meteor test-packages ./ is working, but not meteor publish. The full package is available here.

[mquandalle]

Hum, so here is the message that I got using the new constraint solver:

While selecting package versions:
error: conflict: constraint blaze@2.1.0-rc.2 is not satisfied by blaze
2.1.0-rc.0.
Constraints:
* blaze@=2.1.0-rc.0 <- top level
* blaze@2.1.0-rc.2 <- mquandalle:autofocus 1.0.0
* blaze <- templating 1.1.1-rc.0 <- mquandalle:autofocus 1.0.0

The error was different but it gave me an intuition to solve the problem. It seems that the version of the CLI that you are using to publish a package enforce “top level” constraints on the package dependencies. Thus I successfully “solved” my problem by using meteor publish --release 1.0.4-rc.3.

That seems weird to me ; is that expected?

[dgreensp]

Hi @mquandalle, I'm glad the new error message is a little more helpful!

Yes, that sounds expected. When you run meteor publish, it chooses versions of all the packages needed to build the package. Core packages are always pinned to the "current release." When running meteor commands in the context of the app, the release comes from .meteor/release, and it can also be set (in any context) using --release. In the context of a package, I think it just uses whatever the global "current" version is -- the version you would get running meteor --version from any non-app directory.

[mquandalle]

I'm not sure this is the correct thread to discuss this issue, but I'm still not convinced this is a reasonable behavior. More specifically I find unintuitive that:

1. Despite my explicitly demand for api.versionsFrom('1.0.4-rc.3'); the solver is constrained by an older meteor version due to the CLI “current release”;
2. meteor test-packages ./ and meteor publish are solving the dependency constraints in different ways resulting in different solutions. In the above example I was able to run the tests, but not to publish the package.

[glasser]

A major invariant of Version Solver which makes it much simpler is that it is not invoked to decide what Meteor release to run (except for when you run meteor update without specifying a release explicitly). What release (and thus, what version of Version Solver) gets executed depends solely on things like whether you passed --release, what release your app is pinned to, or what the latest recommended release of METEOR is.

So yes, if you want to publish a package that explicitly declares itself incompatible with all current non-pre-release versions of Meteor, you will also have to tell Meteor that you want to run a prerelease.

[thomasvanlankveld]

When running jasmine tests for a standalone package, using velocity test-package myname:mypackage:

=> Errors prevented startup:

   While selecting package versions:
   error: Conflict: Constraint ecmascript@0.1.6 is not satisfied by ecmascript
   0.1.5.
   Constraints on package "ecmascript":
   * ecmascript@=0.1.5 <- top level
   * ecmascript@0.1.3 <- ddp-server 1.2.1 <- ddp 1.2.2 <- autoupdate 1.2.3
   * ecmascript@0.1.4 <- velocity:html-reporter 0.9.1

In my package.js:

Package.onUse(function(api) {
  api.versionsFrom('1.2.1');
  api.use('ecmascript');

I want to upgrade to version 0.1.6 of the ecmascript package, because I have a breaking for ... of loop (Which I think will solve my problem... the ecmascript package repo is not public and atmosphere doesn't show a changelog).

I can resolve the conflict by changing api.use('ecmascript@0.1.5') at Package.onUse, but is there also a way to use 0.1.6? What does top level mean? Does it refer to api.versionsFrom? Seeing as 1.2.1 is the latest release does that mean it's not actually possible to use 0.1.6 of the ecmascript package? (that'd be weird, because that would mean atmosphere's only available version of the ecmascript documentation does not reflect any available version...)

[btoueg]

Same error/same context as @thomasvanlankveld except that I also have issues with:

• random@1.0.5 is not satisfied by random 1.0.4
• ddp-server@1.2.2 is not satisfied by ddp-server 1.2.1
• mongo@1.1.3 is not satisfied by mongo 1.1.2
• cosmos:browserify@0.8.3 is not satisfied by cosmos:browserify 0.1.4

My CI is crying 🎱

[mitar]

Related: #4610

[hwillson]

This issue originally started before the new Version Solver was launched with Meteor 1.1. So the original issue (unhelpful error messages when package conflicts occur) has been addressed by the Version Solver.

That being said, there is definitely room for improvement. Given that #4610 is an open feature request for better resolution messaging however, I'll close this issue off. Thanks!

[veerjainATgmail]

Its so confusiing... hard to believe, this issue is reported in 2015 (about meteor packaging issues.)