also, in self-test, only set $METEOR_PACKAGE_SERVER_URL for the specific
runs that actually want the test server (using a tag) rather than kinda
always by accident
We were overwriting the server directory when a client-side file changed,
which made all process calls fail, such as process.cwd() and fs.*. We
abstracted out some of the builder code so that only the client targets
are "rebuilt" when a client side file changes.
- in add, we actually do want to know the added version
- in remove, there's a distinction between truly dropping the package
and just dropping the top level constraint
Hopefully this isn't ignoring real error cases. The whole
previousSolution data-rewriting hack probably needs to be fixed
anyway. But this seems to work?
This allows `catalog.official.refresh` to be called during another
refresh that has yielded.
`catalog.official.refresh` still cannot be called re-entrantly, so
`recordOrRefresh` checks if a refresh is in progress before starting a
new one.
Of course, if we were to simply set forceRefresh to true from where
catalog.official was calling catalog.complete.refresh, then we would
have looped inifinitely: initializing the catalog with a `versionsFrom`
field pointing to an unknown release would call
`catalog.official.refresh`, which would call `catalog.complete.refresh({
forceRefresh: true })`, which would call `catalog.official.refresh`
because the unknown release is still not found, and so on.
`catalog.official.refresh` doesn't do any of its actual work when called
reentrantly or when called during a `catalog.official.refresh` yield, so
it makes sense for `catalog.complete.refresh` to be part of that work;
in other words, `catalog.complete.refresh` shouldn't be called if
`catalog.official.refresh` is called reentrantly or during a yield, just
as we don't hit the server again under such conditions. And this also
prevents the infinite loop.
For reasons I don't fully understand, putting the
`catalog.complete.refresh` call before the futures are returned didn't
quite work. Turns out the refreshFutures aren't actually used anyway
(Future wasn't imported from this file; I have a sneaking suspicion the
refreshFutures thing hasn't actually been tested) so this is basically
dead code, and I replaced it with just making `catalog.official.refresh`
return immediately when called re-entrantly or during a yield.
Now we're successfully checking with the server before declaring that a
package/release doesn't exist, and not infinite looping if the
package/release really doesn't exist even on the server.
Specifically, in cases (like "load the most recent release we know
about") where we don't always want to incur a sync RPC.
Apparently, there is literally no way to get data from catalog.official
without a sync RPC occuring.
This speeds up 'meteor --version' on built releases by a factor of 10
