These don't work on Windows because of a Node bug that is fixed in a
newer release. These tests aren't super necessary anyway, so it's
better to comment the empty string ones to let the real ones run
These tests are intended to guard against accidentally working with files
that have colons when on Mac/Linux, and then those packages not working on
Windows. There's nothing to test about the other direction.
Now it reads the value from catalog.DEFAULT_TRACK, which is both more
correct and necessary for the current "preview" state of Windows.
Fixed the following self-tests on Windows:
- run: update during run
- releases: springboard
Unfortunately, the autoupdate self-test still fails, maybe due to a real
bug?
We used to create package directories with the same name as the package
name, but on windows you can't have directories with colons in them.
Now Sandbox.prototype.createPackage takes an additional argument
with the directory name, as distinct from the package name.
This commit updates all the tests that called createPackage to generate
a directory name with no colons.
There were two issues:
1. The meteor.bat file we used to simulate symlinks in Windows didn't
correctly deal with absolute paths
2. The way we overrided DEFAULT_TRACK in Windows led to some other piece
of code not doing the right thing, presumably because it compared
a track to DEFAULT_TRACK which wasn't overridden in Windows.
I found this entire file of commented-out self-tests. The
version-parsing part seems out-dated now, but there are tests of
utils.defaultOrderKeyForReleaseVersion in there that seem legit, which
I re-enabled.
In the return value, `name` has been changed to `package`,
and `vConstraint` is now `versionConstraint`.
`constraint.package` is better than `constraint.name`, where
`constraint` is a PackageConstraint. It's also more consistent
with functions like parsePackageAtVersion which return an object
like `{package, version}`.
`vConstraint` was too cryptic.
Changes were discussed with Glasser in a code review.
Troposphere does not call parseConstraint or work with constraint
objects, so it doesn't need to change.
This is a breaking change to the package-version-parser API (or one
method of it, at least), but it is considered an internal API so we
are not worrying too much about it.
See #3532.
We honestly should probably just drop the option and allow you to type
either a username or a password, just like in accounts-ui.
Because options have to be consistently bool or not across commands (so
that you can put them before the command name), change the testing-only
dummy command's string option to a different nonsense name.
