Previously, we would not write the versions file in this case because
project._recordVersions thought we were doing "run with a different
release temporarily"
Before, we were running the constraint solver with both the new and the
old constraint, which would fail if they were not simultaneously
satisfiable. (We were writing the right thing to disk if it succeeded,
at least.)
Drop the "at-least" constraint type entirely. It was not user-accessible
and was only used in the form ">=0.0.0" to represent a constraint with
no version constraint at all. This type of constraint is now called
"any-reasonable".
The definition of "any-reasonable" is:
- Any version that is not a pre-release (has no dash)
- Or a pre-release version that is explicitly mentioned in a TOP-LEVEL
constraint passed to the constraint solver
For example, constraints from .meteor/packages, constraints from the
release, and constraints from the command line of "meteor add" end up
being top-level.
Why only top-level-constrained pre-release versions, and not versions we
find explicitly desired by some other desired version while walking the
graph?
The constraint solver assumes that adding a constraint to the resolver
state can't make previously impossible choices now possible. If
pre-releases mentioned anywhere worked, then applying the constraints
"any reasonable" followed by "1.2.3-rc1" would result in "1.2.3-rc1"
ruled first impossible and then possible again. That's no good, so we
have to fix the meaning based on something at the start. (We could try
to apply our prerelease-avoidance tactics solely in the cost functions,
but then it becomes a much less strict rule.)
At the very least, this change should allow you to run meteor on a
preview branch like cordova-hcp without getting a conflict between the
prerelease package on the branch/release and the lack of an explicit
constraint in .meteor/packages on that package, because we are
reintepreting the .meteor/packages constraint as meaning "anything
reasonable" and the in-the-release version counts as reasonable.
The idea is that dotfiles in .meteor (like .id and .finished-upgraders)
aren't intended to be human-editable, whereas packages, release,
and versions are (although there are commands to edit them too).
Make sure that project._ensureDepsUpToDate does not get run mid-update,
since it might decide that various things are not compatible with the
packages in the current release. When the update command runs the
constraint solver explicitly, it passes ignoreProjectDeps, but implicit
calls can lead to an unhappy process.exit.
This before was just an uncaught exception. Now it's exit(1), which is
bad too. This should just use buildmessage, but for some reason that
doesn't work here.
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.
Many of these (mostly in top level commands in commands-packages.js) are
not super well thought out: they use a new "doOrDie" helper to run some
function in a capture and exit if there are any messages. We really
need to get a little more thoughtful about the big picture of error
handling (combining "build" errors, network errors, catalog errors,
etc). But this at least allows the addition of more buildmessage
assertions.
At the very least, this ensures that if you edit a package.js in a local
package while "meteor run" is running, that instead of crashing the tool
it properly shows the buildmessage and lets you fix the issue.
Before, there were some random contexts (like 'test-packages') which
didn't print downloads. Now, the default is printing, and the exception
is the automatic background updater.
(Some of these bulk contexts should probably set silent and print their
own progress bar. And maybe even do paralellism...)
Generally clean up the tropohouse.maybeDownloadPackageForArchitectures
interface. Change it to take options, remove the vestigial return
value (though really, there needs to be better error handling...)
Cordova projects often have a different set of files than web targets,
so we would like to be able to target different client architectures in
our bundles. Ideally, we allow the user to use arbitrary client
architectures - but this patch is a step in the right direction by
abstracting out more of the hard coded "browser"/"os" lines.
We accomplish this separation in a backwards compatible way by allowing
api.___ commands to target a "client" architecture. For example,
api.addFiles('a.js', 'client') adds 'a.js' to both the 'client.browser'
and 'client.cordova' targets.
Effects on 0.9 packaging stuff: packages don't have to change, but the
"data.json" file in ".meteor0" has "browser" in some places. We think we
have to fix the troposphere code where this data.json is created.
Some plugins will also be backwards-incompatible with this change, since
many have a "clientArch.matches("browser")" line in the plugin
code. Ideally, we fix plugins so that this stops being an issue, but for
now package authors can just patch that line.
At the compiled (unipackage) level the new names are 'web.browser' and
'web.cordova', replacing 'browser'. In package.js, the new names are
'client.browser' and 'client.cordova', serving as an adjunct to 'client'.
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
