meteor-win
meteor-win copied to clipboard
sdarnell
Downgrade current project version (No compatible build found for npm-bcrypt)
After the release of 0.9.1 for Windows, I want to downgrade my current 0.9.4 project I've been working on in Ubuntu to 0.9.1 for developing on Windows instead. Running meteor update --release 0.9.1 tells me that no such version exists though. I'm not sure this is related to the Windows release, but does anyone have a solution for this?
You might be able to get away with 0.9.0.1 (note the extra zero), but the release probably needs to be referred to as windows:[email protected] so try:
meteor update --release windows:[email protected]
Your solution worked for downgrading my Meteor project. It seems though, that I can't run Meteor with your release. Simply doing meteor create test and running meteor inside the test project, will cause it to hang at "Starting your app...".
It's not too much of a problem, as I can just work in my virtual machine. Just letting you know. Still, thanks for all your effort!
I tried creating a simple test project. Whilst it does seem quite slow, it gets past that stage, and then moves onto "=> App running at: http://localhost:3000/"
I afraid downgrading did not work for me either. After all it states that it is on the speciified version but prints the following error when trying to execute any meteor command:
No compatible build found for [email protected] removed ddp from project removed http from project removed meteor-platform from project removed meteorhacks:kadira-binary-deps from project removed meteorhacks:kadira from project removed mongo from project removed reactive-var from project removed tracker from project upgraded accounts-password from version 1.0.1 to version 1.0.0 upgraded livedata from version 1.0.9 to version 1.0.7 upgraded session from version 1.0.1 to version 1.0.0 upgraded spacebars-compiler from version 1.0.2 to version 1.0.1 upgraded blaze from version 2.0.0 to version 1.0.3 upgraded spacebars from version 1.0.1 to version 1.0.0 upgraded templating from version 1.0.5 to version 1.0.4 upgraded follower-livedata from version 1.0.1 to version 1.0.0 upgraded deps from version 1.0.3 to version 1.0.1 upgraded autoupdate from version 1.0.6 to version 1.0.5 upgraded accounts-base from version 1.0.1 to version 1.0.0 upgraded application-configuration from version 1.0.1 to version 1.0.0 upgraded less from version 1.0.7 to version 1.0.6 upgraded reload from version 1.0.1 to version 1.0.0 upgraded iron:dynamic-template from version 0.4.1 to version 0.3.0 upgraded ctl from version 1.0.1 to version 1.0.0 upgraded iron:router from version 0.9.3 to version 0.9.0 upgraded ctl-helper from version 1.0.3 to version 1.0.2 upgraded iron:layout from version 0.4.1 to version 0.3.0 upgraded standard-app-packages from version 1.0.1 to version 1.0.0 upgraded minimongo from version 1.0.2 to version 1.0.1 upgraded service-configuration from version 1.0.1 to version 1.0.0 upgraded reactive-dict from version 1.0.2 to version 1.0.0 upgraded accounts-ui-unstyled from version 1.0.1 to version 1.0.0 upgraded meteor from version 1.0.3 to version 1.0.2 upgraded webapp from version 1.0.3 to version 1.0.2 upgraded ejson from version 1.0.1 to version 1.0.0 upgraded mongo-livedata from version 1.0.4 to version 1.0.3 upgraded iron:core from version 0.3.4 to version 0.3.2 upgraded observe-sequence from version 1.0.2 to version 1.0.1 upgraded ui from version 1.0.2 to version 1.0.0 Could not install all the requested packages.
meteor update --release windows:[email protected] Refreshing package metadata. This may take a moment. This project is already at Meteor 0.9.0.1-rc3.
@danielsvane Please could you delete the %LOCALAPPDATA%\.meteor directory and re-install. Then use meteor update --release windows:[email protected] hopefully it should work.
@cguettinger Please could you try editing the versions file in the .meteor directory and change:
[email protected]
to
[email protected]
This may work, but I doubt it. The problem seems to be that one of the packages you have seems to have an explicit dependency on the core npm-bcrypt. It may help to pin down which package the dependency comes from.
One faulty package is accounts-password.
Whenever I try to install it using meteor add accounts-password, I get the following error:
No compatible build found for [email protected]
Package npm-bcrypt has no compatible build for version 0.7.7
There is no [email protected] in my versions file. I added [email protected] at the end, but then I got:
removed windows_npm-bcrypt from project
No compatible build found for [email protected]
Package npm-bcrypt has no compatible build for version 0.7.7
(and [email protected] has been removed from the file).
About package versions:
- Version 1.0.0 gives the above error.
- Versions 1.0.1 to 1.0.4 give the following error:
Could not satisfy all the specified constraints: Error: conflict: accounts-password can't be satisfied
Hmm, the strange thing is that using the 'checkout' build of meteor, I can successfully add 'accounts-password' (1.0.0), but when I use the released version it doesn't work.
Even stranger, is if I disable WIFI so that it can't possibly download a different package from the package server, and try the released version - it still fails. But the local package accounts-password has the correct dependency in the os.json file.
"uses": [
{
"package": "meteor"
},
{
"package": "windows:npm-bcrypt",
"constraint": "=0.7.7"
},
What seems to be happening is that dependencies are being loaded from the package server metadata and not the local package itself. (I thought I could cheat a bit to drop in the windows replacement from bcrypt).
Presumably the 'checkout' version actually uses the package definition rather than the cached metadata.
By the way, the reason that I'm trying to cheat is that the package system is overly tight in some respects. accounts-password depends on npm-bcrypt, but I don't have permission to release npm-bcrypt. So I have released windows:npm-bcrypt (which is fine). But to follow the rules I would have to release a windows:accounts-password to update the dependencies, etc. and that would pull in all of he accounts packages transitively. And users would have to change their app dependencies etc. In other words, a whole load of pain. (sad face)
I'll just have to find some way of intercepting the metadata in the same way I swizzle the api.use() call.
I was hoping to get some suggestions from a meteor-core post, but nothing useful. The other development is that MDG have started on a Windows port and I was expecting a MDG released bcrypt to be available, but unfortunately they've gone down the route of adding a '-winXX' suffix to all packages - and this makes things even worse.
I did look at doing some sort of alias for packages, but the constraint solver and package code is so complex that I haven't managed to get a variant that works.
For reference, here is what MDG' Meteor port says when running meteor add accounts-password:
C:\myproject>meteor add accounts-password
removed mongo-livedata from project
upgraded livedata from version 1.0.7 to version 1.0.11-win.0
upgraded session from version 1.0.0 to version 1.0.4-win.0
upgraded spacebars-compiler from version 1.0.1 to version 1.0.3-win.0
upgraded blaze from version 1.0.3 to version 2.0.3-win.0
...
<more packages here>
...
upgraded htmljs from version 1.0.0 to version 1.0.2-win.0
upgraded blaze-tools from version 1.0.0 to version 1.0.1-win.0
upgraded minifiers from version 1.0.2 to version 1.1.2-win.0
upgraded callback-hook from version 1.0.0 to version 1.0.1-win.0
In order to resolve constraints, we had to use the following
experimental package versions:
[email protected] Wrapper around the bcrypt npm package
added accounts-password at version 1.0.4-win.2
added accounts-base at version 1.1.2-win.0
added service-configuration at version 1.0.2-win.0
added sha at version 1.0.1-win.0
added localstorage at version 1.0.1-win.0
added srp at version 1.0.1-win.0
added npm-bcrypt at version 0.7.8-win.0
accounts-password: Password support for accounts
Pardon the naive question, but I am new to distributed package deployment... When packaging my application for production, I must be allowed to choose and to lock down dependency rules, package versions and package source code. This way I can test, ship, maintain and patch a frozen product. For example, I might need to fix a bug in a third-party package, replace a dependency by another (leaving further ancestors untouched), upgrade only one package to a newer version, etc. Does it make sense? If it does, does the current issue imply that Meteor has no such feature?
My understanding of the way that Meteor works is that the constraint solver will try to find matching compatible packages when you run update, but will not deliberately update packages for no good reason.
As things stand, I think meteor update does two things. It can update updates the version of meteor being used, and also updates packages to the latest versions.
The distinction between what the constraint solver does and what meteor update does is probably useful. You should for example be able to update the versions file in .meteor without doing a meteor update. In this way you should be able to specify exactly which versions you want - with the constraint solver giving an error if you get it wrong. You can use meteor update but it may change lots of things without you're active selection. But if you dislike what meteor update does, you should be able to go back to a previous version of the versions file (you're tracking it in source control of course), and you're back to where you started.
This particular bug report relates to the constraint solver not being able to find matching packages because there is no accounts-password that refers to the windows version of bcrypt. Sadly the MDG decided to branch every package version for the windows preview. The two best options forward are:
- MDG release core binary packages for Windows
- I modify the constraint solver to accept windows:npm_bcrypt as a substitute for (core:)npm_bcrypt
Thanks for the clarification. I guess the rational option is to wait for MDG to move forward. However, having tried their windows preview, I am not so reassured. But I am probably too eager...
@sdarnell, as you said above: "I did look at doing some sort of alias for packages, but the constraint solver and package code is so complex that I haven't managed to get a variant that works."
From MDG, a few days ago (https://github.com/meteor/meteor/issues/2846#issuecomment-62035618): "Basically, we learned a whole lot about our package system by implementing it in 0.9. What we ended up building is a little bit more complicated and hard to describe and implement than what we actually need, but we only learned that through the exercise of actually building it! We're now taking a second pass and simplifying a lot of things, which should both simplify the implementation and make it easier for users to understand. I'm pretty excited about where this is going."