The logic at the top of this function was basically just for the case of
"file is in imports but also a test file". But the logic caught up some
other edge cases, such as "file is in node_modules but also a test file".
After running `meteor build` in created archive `Readme` file with next content:
```text
This is a Meteor application bundle. It has only one external dependency:
Node.js 0.10.40 or newer. To run the application:
$ (cd programs/server && npm install)
$ export MONGO_URL='mongodb://user:password@host:port/databasename'
$ export ROOT_URL='http://example.com'
$ export MAIL_URL='smtp://user:password@mailhost:port/'
$ node main.js
Use the PORT environment variable to set the port where the
application will listen. The default is 80, but that will require
root on most systems.
Find out more about Meteor at meteor.com.
```
Since Meteor@1.4 requires nodejs@4.4.7 and fails on nodejs@0.10.*, generated `Readme` must be updated
This reverts commit 9e6ebde836.
Now that the `dev_bundle` link is called `.meteor/local/dev_bundle`, and
`.meteor/local` is already ignored, we don't need to ignore
`.meteor/dev_bundle` anymore.
If a developer tried to `meteor update` a project whose `.meteor/release`
file corresponded to a version of `meteor-tool` that no longer exists in
`~/.meteor/packages/meteor-tool`, this code would throw an ENOENT error.
This could be fixed by running `meteor update --release <old release>`
first, but that kind of workaround shouldn't be necessary when updating
Meteor to the latest version.
As a refinement of my previous commit, we will continue setting the
$GYP_MSVS_VERSION variable to "2015" except in cases where the Python
library behind node-gyp succeeds in inferring the correct version.
Note that the Python library will never infer "2015" by itself, even
though that's the version recommended by the node-gyp setup instructions:
https://github.com/nodejs/node-gyp#installation.
Note also that the Windows machines used by `meteor admin get-machine` and
build.meteor.com have version "2010e", which can be inferred.
In other words, this commit allows the following groups of developers to
avoid setting $GYP_MSVS_VERSION manually:
1. Developers who followed the node-gyp setup instructions.
2. Package authors who run `meteor publish-for-arch` on build machines.
Setting GYP_MSVS_VERSION to 2015 when the Visual C++ 2015 build tools are
not (and/or cannot be) installed is (in my experience) the leading cause
of `npm rebuild` failures on older Windows machines.
Auto-detecting the appropriate version is something node-gyp ought to be
able to do as well as Meteor possibly could, at least according to
https://github.com/nodejs/node-gyp/blob/1dcf356ca7/gyp/pylib/gyp/MSVSVersion.py#L222-L223
When selecting a different version is important, you can always set the
GYP_MSVS_VERSION environment variable yourself. Specifically, if you're a
package author, and your package depends on npm packages that can only be
compiled with a newer version of MSBuild.exe, then you might need to run
$env:GYP_MSVS_VERSION = "2015"
meteor publish-for-arch name:package@x.y.z
I fully trust that the folks in that small category can handle that
additional burden.
We now use a smaller file (the `babel-compiler` archive instead of
`meteor-tool`), and we interrupt every 500kB, which leads to three total
interruptions for that file. Also, we only delay one second (instead of
five) between attempts.
This is a test that really needs to run and pass every time we run the
test suite, so I decided it shouldn't be --slow. If it takes too long, we
can always download a smaller test file.
Hard-coding the download length was a recipe for brittleness, so now I'm
downloading the file without interruptions in parallel with the
interrupted/resumed download, so that we can compare the two files when
both have finished downloading.
Follow-up to #7399.
I'm deliberately leaving in the code to ensure .meteor/.gitignore contains
dev_bundle for now, so that the old file won't get accidentally checked
into anyone's app repository.
