Not sure what the original motivation for printing <unknown> was (it
shouldn't ever come up in normal operation, only if something weird
happens like we manually unset a user's username in the database). But
it's now rather inconvenient because we don't yet clean up deleted
organizations from a site, so you would see <unknown> for every
authorized organization that has been deleted. While we should
eventually clean up deleted organizations from a site's
"authorized_orgs" field, for now this will clean up the output of this
command.
We're going to make uniload use a different flavor of "complete" catalog
soon. So we need to reduce the number of singleton-ish references to
it.
Also, we need one PackageCache per catalog, so stop it from being a
singleton too.
Also eliminated arguments that weren't used anywhere,
and removed an XXX comment that was false (recordPackages
doesn't use buildmessage to report connection failures)
Port a simplified version of Meteor.EnvironmentVariable and
Meteor.bindEnvironment to fiber-helpers.js to deal with this.
Identify uses of fiberHelpers.inFiber and switch them to either
fiberHelpers.bindEnvironment (if the callback they are wrapping is
semantically "part of" the context that creates the callback) or
fiberHelpers.inBareFiber (otherwise).
Without this, concurrency was causing the wrong buildmessage message
sets and jobs to be active when builds yielded.
Moving towards a world where all things that might invoke buildmessage.error are
encouraged to be in a buildmessage.capture.
This commit is the answer to the question "how many small changes need to be
made to add buildmessage.assertInCapture to PackageCache.loadPackageAtPath?"
Next steps include:
- Making catalog.resolveConstraints ALWAYS buildmessage.assertInCapture
(not just when ignoreProjectDeps isn't passed)
- Then changing resolveConstraints to complain using buildmessage
- Removing the process.exit(1) in _ensureDepsUpToDate
- Adding a more structured way to ensure that most commands
call _ensureDepsUpToDate at an unsurprising location
symlink as a special case for runner only
future commits on this branch will add a
package.json/npm-shrinkwrap.json that can be used by "meteor bundle"
users
When we deploy:
* If we are logged in with a username, then we go straight to doing the
actual deploy.
* If we are logged in without a username, we check if we have a username
yet. If we have an invalid credential at this point, we do NOT want
`pollForRegistrationComplete` to wipe our session file, because we
already passed the point at which we handle the case of the user being
logged out. Instead, we just want to continue with the deploy and let
the deploy server handle the expired credential. (This case, where a
user's credential has been expired before they set a username,
shouldn't happen too often in real life.)
* If we deploy with an invalid credential, we get an "Expired
credential" message.
