This reverts commit 89b394d974.
I cherry-picked the change onto devel, since this change isn't
even supposed to change the behavior of the tool. Why risk
it just before the release? Thanks @nim for the suggestion.
The test was failing because it was written to run against the real
local warehouse, instead of a stubbed one. When initializing the
Sandbox with an explicit warehouse, the test failed because of
incorrect logic piping the right path to the packages database
(in this case "test-packages.data.db" instead of "packages.data.db").
Unfortunately, the test still fails -- this time potentially due to a bug:
After publishing the package for the first time with `--create`,
the next step tries to update but gets the following error:
There is no package named test:i1iyhj. If you are creating a
new package, use the --create flag.
This is a regression caused by the SQL merge. Sorry for not catching it earlier!
We should not be calling semver on meteor package versions outside of the package
version parser package.
This should mean that you can access the package server from behind a
corporate firewall.
I tested this by setting up a Linux machine that doesn't have access to
packages.meteor.com:
$ sudo iptables -A OUTPUT -d 54.225.216.115 -j DROP
$ sudo iptables -A OUTPUT -d 184.72.252.20 -j DROP
$ sudo iptables -A OUTPUT -d 23.23.114.56 -j DROP
I confirmed that these commands both fail:
$ curl https://packages.meteor.com/
$ ./meteor search asdf # when it needs to sync first
I bought a proxy server from Proxy Bonanza and confirmed that setting
the environment variable HTTPS_PROXY to
https://PROXYUSERNAME:PROXYPASSWORD@PROXYIP:PROXYPORT/
made both of the commands above succeed.
Fixes#2515.
This commit introduces some conviluted logic to keep the old behavior of the
meteor bundle command. Hopefully we will drop it soon so we will simplify the
logic.
If we don't clean up the tarball, then the following command (`meteor
build`) fails ("Couldn't create tarball"), but for some reason still
exits with code 0. So we then go on to successfully untar the output of
`meteor build`. If we clean up the tarball from `meteor bundle`, we at
least catch the failure by trying to untar a nonexistent file.
The client cache in sql-land was broken: it sent over the wrong sync token as the default.
This meant that the server thought that this was a much older client. As a result, any
0.9.3+ packages with '_' or '||' in their versions/dependencies were filtered out. There is no
easy way to undo that sort of filtering without deleting the db for a variety of reasons, and if
we are going to delete the db, we might as well increment the version so we don't have to worry about
consistency.
If we fail to install one plugin, then we uninstall all plugins to avoid
awakening the Cordova monsters. Previously, this test was passing
because we were passing a `--settings` argument, which was allowing the
facebookconnect plugin to install, but the build to fail to other,
not-understood reasons. Now that we've removed `--settings`, the plugin
fails to install, which means that all plugins get uninstalled.
Test passes now.
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
