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.
