New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

package system defaults to ancient versions if no semver is specified? #3282

Closed
dcsan opened this Issue Dec 12, 2014 · 23 comments

Comments

Projects
None yet
7 participants
@dcsan

dcsan commented Dec 12, 2014

if add a package with no semver specified it will default to the oldest version:

# .meteor/packages
aldeed:autoform

$ meteor update
  downgraded aldeed:autoform from version 4.0.0 to version 0.17.1
  downgraded aldeed:collection2 from version 2.2.0 to version 0.4.6

at the very least this seems wrong, it should default to the newest version?

separately, if I specify a recent version, however there is no way to say "at least 4.0" with meteor's flavor of semver. both of these:

   aldeed:autoform@4.0.0
   aldeed:autoform@=4.0.0

will pull in 4.0.0 where currently that package is at 4.2.0 .
afaik there is no support for something like

aldeed:autoform@>4.0.0
@glasser

This comment has been minimized.

Member

glasser commented Dec 12, 2014

Can you provide a full cloneable reproduction? Ideally with 1.0.2-rc.1.

@dcsan

This comment has been minimized.

dcsan commented Dec 12, 2014

I can't repro this with 1.0.2

which btw seems blazingly fast at reloading everything!! if this is the long awaited speedup code drop, there's no way i'm going back to 1.0 :) woohoo!

@dcsan dcsan closed this Dec 12, 2014

@RobertLowe

This comment has been minimized.

Contributor

RobertLowe commented Dec 25, 2014

@glasser I ran into the same issue when running a routine meteor update from 1.0.2 to 1.0.2.1 now my deps are trying to depend on older versions, even after trying to downgrade back to meteor update --release 1.0.2.

The issue for me was with aldeed:autoform & aldeed:collection being downgraded to 0.1.0.

I fixed the issue by removing the offending packages from .meteor/packages which had deps on it, running meteor add aldeed:autoform@4.2.0 then meteor add aldeed:collection2@2.3.0, I then updated the local packages deps to include specific versions, removed the two packages from .meteor/packages. Finally I restarted meteor and it was satisfied.

Something about meteor update, meteor add and unspecified versions works a little wonky.

I can't push this to a public repo either.

Cheers.

@glasser

This comment has been minimized.

Member

glasser commented Dec 27, 2014

@dgreensp Is this something you can look into, since you're working on stuff with the constraint solver anyway? The constraint solver is definitely supposed to try hard to avoid downgrading anything if possible.

@dgreensp

This comment has been minimized.

Contributor

dgreensp commented Dec 27, 2014

I can look into it.

Thoughts off the top of my head: The constraint 4.0.0 does mean "at least 4.0.0 (but less than 5.0)". meteor update is supposed to prefer newer versions. However, the currently released solver doesn't globally optimize, or even try very hard to locally optimize once all constraints are satisfied. I'm working on a rewrite of the constraint solving algorithm that should help.

As always, cloneable reproductions are greatly appreciated.

@dgreensp

This comment has been minimized.

Contributor

dgreensp commented Jan 8, 2015

@dgreensp

This comment has been minimized.

Contributor

dgreensp commented Jan 13, 2015

@RobertLowe, to clarify, your problem was with packages being downgraded that weren't listed in .meteor/packages, but were dependencies of packages listed in .meteor/packages, correct?

@RobertLowe

This comment has been minimized.

Contributor

RobertLowe commented Jan 13, 2015

@dgreensp Yes, I believe that's the case, I'm mobile right now so if memory serves that is correct.

It happens when dependacies are left unspecified.

Cheers

dgreensp added a commit that referenced this issue Jan 13, 2015

“meteor update” can update non-root dependencies
Previously, “meteor update foo” meant “ignore .meteor/versions for foo”,
which would upgrade if “foo” was a root dependency, and downgrade if foo
was only a transitive dependency.

Now, we make sure to try to upgrade foo even if it is not a root
dependency.

See #3282.
@dgreensp

This comment has been minimized.

Contributor

dgreensp commented Jan 13, 2015

Fixed on devel.

What meteor update foo means is: Update the version of foo in .meteor/versions, and also edit the versions of its dependencies as necessary to satisfy all constraints. The constraints on direct dependencies in .meteor/packages are maintained at all times. Before this fix, meteor update foo only did-what-you-meant if foo was a direct dependency. If foo was an indirect dependency (depended on by a package), it would actually downgrade foo instead of upgrading it. This is now fixed.

@dgreensp dgreensp closed this Jan 13, 2015

@RobertLowe

This comment has been minimized.

Contributor

RobertLowe commented Jan 13, 2015

Thanks @dgreensp you're awesome!

@arunoda

This comment has been minimized.

arunoda commented Jan 14, 2015

This may be somewhat related to this issue.

  • I've pushed my app into git from a mac
  • Then I trying to build it from a CI server (linux)
  • Then I see something like below:
=> Started proxy.

Changes to your project's package version selections:

anti:gagarin                 downgraded from 0.3.3 to 0.3.0
meteorhacks:flow-components  downgraded from 0.0.20 to 0.0.13
meteorhacks:flow-router      downgraded from 0.0.12 to 0.0.2

None of these is a binary package. I think this is something relevant to this issue.
Is this fix comes with 1.0.3-rc.0 ?

@dgreensp

This comment has been minimized.

Contributor

dgreensp commented Jan 14, 2015

Did you commit .meteor/versions? Just running the app shouldn't change the versions for no reason.

@arunoda

This comment has been minimized.

arunoda commented Jan 14, 2015

Ah yes. it's there.
That's why it's mentioning downgraded from 0.3.3 to 0.3.0
(0.3.3 is the version in the .versions file)

@RobertLowe

This comment has been minimized.

Contributor

RobertLowe commented Jan 14, 2015

@dgreensp OT: Is there a way to dump a dependancy's tree of dependancies? This would be fairly useful... As of right now it's a bit difficult to see what a dependancy is built on top of other then digging through atmosphere.

Cheers

@dgreensp

This comment has been minimized.

Contributor

dgreensp commented Jan 15, 2015

@arunoda If you revert .meteor/versions and run again, does it downgrade again, reproducibly? That sounds like a bug that I'd like to reproduce. However, I suspect it is because if anything triggers a full run of the constraint solver, indirect dependencies may get downgraded. That suggests a second question. After you get the "downgraded" message, if you change only those versions back to what they were, does it downgrade again?

My fix only address what happens when you run meteor update, but it allows you to run meteor update anti:gagarin meteorhacks:flow-components meteorhacks:flow-router and have it work even if those packages aren't direct (i.e. top-level) dependencies. The fix is included in 1.0.3.

@RobertLowe You're in luck. There's no tree, but as of 1.0.3-rc.0, meteor show foo-package@1.0.0 will list the dependencies of foo-package@1.0.0. Thanks go to ekate for this feature.

@arunoda

This comment has been minimized.

arunoda commented Jan 15, 2015

@dgreensp It's hard to reproduce. Only happens on some linux boxes only. Yes, if I updated again with meteor update it will work correctly.

I try to find if it can be reproduced. Then I'll share the linux VM with you.

@queso

This comment has been minimized.

Contributor

queso commented Jan 28, 2015

I am getting this with codeship test running. When I run the app in the codeship environment, it downgrades the app from 0.3.6 to 0.3.4 (xolvio:cucumber) for some reason.

Will see if I can make a quick repro of it.

@krstffr

This comment has been minimized.

krstffr commented Feb 2, 2015

I'm getting this error when deploying to Heroku servers using the https://github.com/AdmitHub/meteor-buildpack-horse buildpack. Random packages get downgraded unless I specify an exact version for them (running meteor add author:package@1.2.3 for example).

@queso

This comment has been minimized.

Contributor

queso commented Feb 2, 2015

Yes, mine turned out to be the same issue, with no semvar it seemed to just randomly downgrade. Once I pegged xolvio:cucumber@0.3.6, it worked fine on install.

@glasser should we open a new issue since this one is closed?

@dgreensp

This comment has been minimized.

Contributor

dgreensp commented Feb 2, 2015

Is there any way we can reproduce this? I'd love to get to the bottom of it!

The part that's hard to figure out is that meteor should use the versions in .meteor/versions, which should be checked into your repo. If it needs to choose different versions for some reason -- which may be possible to trigger based on architecture? I'm not sure -- it should write the new versions to .meteor/versions. So you should at least be able to see the "paper trail" in .meteor/versions, and reproduce the downgrade repeatedly by reverting it.

Are you able to get the message repeatably? Thanks.

@queso

This comment has been minimized.

Contributor

queso commented Feb 2, 2015

I will see if I can get a simple repo up and repro on codeship... It has a debug console so you can ssh in and play around with the box directly... I have seen it happen 2 out of 2 times on codeship so far without cucumber being pegged to a version.

@queso

This comment has been minimized.

Contributor

queso commented Mar 14, 2015

@dgreensp I assume MiniSat should solve this?

@dgreensp

This comment has been minimized.

Contributor

dgreensp commented Mar 14, 2015

My understanding is that this issue and #3653 are fixed on devel, and in the METEOR@new-version-solver-2 release (and the upcoming 1.1 RC).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment