* --port now requires a port ('meteor run --port example.com' isn't valid).
* --mobile-server defaults to your detected IP address and the port from
--port.
* If you provide a value for --mobile-server, we default to http:// as
the protocol. A host is required for --mobile-server if you don't omit
the option entirely. Similar for the --server argument to 'meteor
build'.
This commit includes the 'netroute' npm module as a core package (which
has binary dependencies) for IP detection. It would be nice to put it in
packages/non-core, but I think it has to be a core package in order to
uniload it.
When we publish things to the test packaging server, we use the versionsFrom
argument that is very difficult to set up right to actually work. Most of the time
we don't really set that up and just agree that those tests should fail. As such, I
am going to mark most of those tests as checkout-only for now (we still usually check
that we can publish manually anyway as part of poking at the release in QA, and there is
not a lot of reason that I can think of why publishing from release would be different than
pubishing from checkout. So, marking these as checkout-only until we can get a better
testing infrastructure for this in place.
Rewrote parts of the update server package data unit test to compare a pre-sync and a
post-sync catalog, rather than the output of package client's attempts to contact the server.
This is because in the new world, there is no accurate output, and instead, the function
modifies the catalog in place. Additionally, removed the old function that read from
data.json, since it was not used anymore, and cleaned up some comments and return values in
package-client. We no longer claim to return the contents of data.json, instead we return
an object that signals if we should reset the entire catalog, and/or if our connection to the
server flat-out failed. I am not sure that this is the best abstraction for this piece of code
(why does package-client modify the catalog, but not reset it, for example? Since resetting
has consequences, in the ideal world, the package-client would only have the logic to get data
from the server and it would be up to the catalog to figure out how to insert it into sql lite,
I think, maybe. Regardless, now is not the time to do that refactoring.)
The test is a little odd in the following ways. First, comparing every record ever published is
something that is already significantly harder than it used to be, and will get only harder from
there. (However, the test claims to check that no data has been erased, so we need to check it).
We check the vague existence of most records, on the theory that it is unlikely that
we only got a portion of the record in, rather than the entire thing. Second, it doesn't check the
actual contents on disk, because I wasn't sure about writing another interface to sqllite this
late in the game. There are some ways to get around this -- we could be sneaky and submit a non-blank
syncToken in some way (faking a previous sync), so we only get the packages touched since (time X).
Usually, that might violate some internal consistency, but we only care about the contents at this stage.
Second, we should probably write some method on the catalogs to compare themselves instead of making
and querying a copy.For now, though, I think that this is sufficiently expedient.
Also, the test publishes 5 packages. That's a lot of packages, so I marked it as slow.
If you pass "--parent-pid foobar", then we immediately log an error
message and exit. This check happens via `parseInt` rather than testing
for exceptions in `process.kill(parentPid, 0)` because `process.kill`
converts its pid argument to an integer, so `process.kill('foobar', 0)`
returns true just as `process.kill(0, 0)` does.
As of 3e64bd78, this usage of `reload` no longer works (if we set a
project's root dir to a fresh app, and then run the app which computes
versions.json, and then call `reload`, we'll end up with the project's
dependencies being empty). Maybe this is a bug in `reload`, but it
probably doesn't matter for any usage other than this test, and maybe
this test was misusing `reload` in the first place.
This allows us to later increase the pool for well-formed versions without requiring
moving the catalog's data.json into a new folder, which would require re-syncing
the entire catalog.
1. Fixes the test for updating to a new rc. First, change the ordering -- since we order RCs now, it means that if you add rc.3 while
rc.4 is available it just adds rc.4. So, now, we publish rc.4 after rc.3 has been added, run update (with the right options) and
check that it worked.
2. When you run list, we check if there are newer versions of packages. Usually we just look at mainline versions. But if you are already
using an rc version of a package, you might care about new rcs too. So, in that case, we check the latest of *all* available versions.
