installation issues with versions 1.5.x on Windows 10

[cormip]

Sorry, didn't realize I had accidentally committed an empty comment. I am having trouble installing:

meteor add vsivsi:job-collection

It stays stuck on Loading... vsivsi:job-collection@1.5.1... for hours?!

I stopped it, and successfully added and removed other packages without issues. I updated Meteor to 1.4.4_1 and still get the same problem.

Is there a log I can look at to see what's taking so long?

[vsivsi]

@cormip What's the issue? I'm not seeing any text in your description.

[cormip]

Left it overnight... still running 12 hours later. Something isn't right.

[vsivsi]

Can you successfully install version 1.4.0?

[cormip]

Yes! v1.4.0 installed without any problems! I then tried updating it to 1.5.1 and it was again stuck on Loading...

[vsivsi]

Hmmm, okay, I'll try to reproduce this today. Thanks for reporting!

[vsivsi]

Hi, I'm not able to reproduce this issue.

Here's what I tried. I have a simple "empty" Meteor app project here: https://github.com/vsivsi/emptyMeteorProj

git clone https://github.com/vsivsi/emptyMeteorProj.git emptyProj
# Cloning into 'emptyProj'...
# remote: Counting objects: 101, done.
# remote: Total 101 (delta 0), reused 0 (delta 0), pack-reused 101
# Receiving objects: 100% (101/101), 18.65 KiB | 0 bytes/s, done.
# Resolving deltas: 100% (32/32), done.

cd emptyProj
meteor npm install
# /Users/vsi/emptyProj
#└─┬ babel-runtime@6.23.0 
#  ├── core-js@2.4.1 
#  └── regenerator-runtime@0.10.3 
# npm WARN emptyProj No repository field.

meteor
# [[[[[ ~/emptyProj ]]]]]                       
# => Started proxy.                             
# => Started MongoDB.                           
# => Started your app.
# => App running at: http://localhost:3000/

# ^C

meteor add vsivsi:job-collection
# Changes to your project's package version selections:
# mrt:later              added, version 1.6.1   
# vsivsi:job-collection  added, version 1.5.1
# vsivsi:job-collection: A persistent and reactive job queue for Meteor, supporting distributed workers that can run anywhere

meteor
# [[[[[ ~/emptyProj ]]]]]                       
# => Started proxy.                             
# => Started MongoDB.                           
# => Started your app.                          
# => App running at: http://localhost:3000/

So it doesn't appear to be blatantly broken for installing. Please try to reproduce these steps and let me know what you get.

To proceed, I'm probably going to need you to produce a detailed step-by-step minimal reproduction of the issue you are seeing. Please include information about the platform(s) you are seeing this on, etc. This may be something specific about your setup or ???

[cormip]

OK, I'm on a new Windows 10 PC. I have several Meteor projects that I am able to successfully develop on this machine without issues.

I performed the following simple test:

D:\temp>meteor create vsivsiTest
Created a new Meteor app in 'vsivsiTest'.

To run your new app:
  cd vsivsiTest
  meteor

If you are new to Meteor, try some of the learning resources here:
  https://www.meteor.com/learn

meteor create --bare to create an empty app.
meteor create --full to create a scaffolded app.

D:\temp>cd vsivsiTest

D:\temp\vsivsiTest>meteor add vsivsi:job-collection
   Loading vsivsi:job-collection@1.5.1...    \

Stuck on Loading...

So that eliminates any potential conflicting packages in my app. There must be a dependency it needs on my machine?

[cormip]

I also exactly duplicated your steps above with the same result:

D:\temp>git clone https://github.com/vsivsi/emptyMeteorProj.git emptyProj
Cloning into 'emptyProj'...
remote: Counting objects: 101, done.
remote: Total 101 (delta 0), reused 0 (delta 0), pack-reused 101
Receiving objects: 100% (101/101), 18.65 KiB | 0 bytes/s, done.
Resolving deltas: 100% (32/32), done.

D:\temp>cd emptyProj

D:\temp\emptyProj>meteor npm install
D:\temp\emptyProj
`-- babel-runtime@6.23.0
  +-- core-js@2.4.1
  `-- regenerator-runtime@0.10.3

D:\temp\emptyProj>meteor
[[[[[ ~\D\temp\emptyProj ]]]]]

=> Started proxy.
=> Started MongoDB.
=> Started your app.

=> App running at: http://localhost:3000/
   Type Control-C twice to stop.

=> Client modified -- refreshingTerminate batch job (Y/N)? y

D:\temp\emptyProj>meteor add vsivsi:job-collection
   Loading vsivsi:job-collection@1.5.1...    -

[vsivsi]

Hmm, must be a Windows dependency of some kind. I only develop on MacOS and Linux. I literally have no access to a Windows 10 box to even test this on.

So technically, my package isn't even running during the "meteor add" step. Meteor is running. The package was published to Atmosphere using Meteor and it was accepted. And Meteor is what is hanging when you try to add it to a project under Windows.

Even if I could reproduce it, I'm not sure what there is for me to fix here... It's not my code that is hanging.

One thing to try is to see if the package will pass its own unit tests under windows:

git clone --recursive https://github.com/vsivsi/meteor-job-collection.git
cd meteor-job-collection
meteor test-packages ./
# Now open a browser to localhost:3000

If that works, then you can try adding it manually to your project:

# In the root directory of your meteor project
mkdir packages
cd packages
git clone --recursive https://github.com/vsivsi/meteor-job-collection.git
cd ..

Now edit .meteor/packages and add the line vsivsi:job-collection@1.5.1

Now if you run meteor you should see it build the job-collection package without error.

Something like:

Changes to your project's package version selections:

mrt:later              added, version 1.6.1   
vsivsi:job-collection  added, version 1.5.1

Give those things a shot and let me know what happens.

[cormip]

The package did successfully pass 46 of 46 tests on Windows.

I'm already well down the path of "Plan B" on my project, so I'll have to see if I'll need to revisit trying to use vsivsi:job-collection at some later time.

[vsivsi]

Okay, well, it looks like the package itself runs fine on Windows (and there's no reason it shouldn't). So something is goofed up with Meteor's add functionality on Windows. I'll bet that the manual install above will work, but obviously that's not ideal. Let me know if you need any other assistance on this.

[cormip]

OK, FYI, I must have >50 different Atmosphere packages and npm modules in my various Meteor projects, and none of them have given me this kind of a problem. Apparently, something changed in your 1.4.0 -> 1.5.0 update, since 1.4.0 installs just fine.

[vsivsi]

Good to know. For me the mystery is:

a) 1.5.1 install works fine on OS X and Linux b) No job-collection code actually runs during meteor add c) job-collection itself apparently runs fine on Win 10

Just one other question, have you tried installing version 1.5.0 (not 1.5.1)? Just curious whether the issue is really a change in 1.5.0 (that persists in 1.5.1). Besides my code itself, the other thing that changed between 1.4.0 and 1.5.x is the version of Meteor I used to package and publish it to Atmosphere. 1.4.0 was published way back in May of 2016. 1.5.0 was last weekend...

But the real issue for me with this is that even if I could reproduce this on my own Windows machine, I would be debugging Meteor source code trying to get to the source of the hang, since no code that I authored should be running during that operation...

[cormip]

1.5.0 also hangs at Loading.

Clue: I believe the problem is related to node-gyp because a) the native build for Windows is different than for Linux & OSX, b) The command shell title changes based on the different steps being executed during the meteor add, and the title bar says "node-gyp" when it hangs.

I did confirm that node-gyp is working fine on my machine by installing several other modules that require node-gyp to be working. See:

https://github.com/Microsoft/nodejs-guidelines/blob/master/windows-environment.md#verify-everythings-working

[vsivsi]

job-collection doesn't require node-gyp. There are no binary dependencies. And the dependencies didn't change (except for minor revs) between 1.4.0 and 1.5.1

meteor show vsivsi:job-collection@1.5.1
# Depends on:                                   
#   check@1.2.5                                 
#   coffeescript@1.12.3_1
#   isobuild:isopack-2@1.0.0
#   mongo@1.1.16
#   mrt:later@1.6.1

meteor show vsivsi:job-collection@1.4.0
# Depends on:                                   
#  check@1.2.1                                 
#  coffeescript@1.0.17
#  isobuild:isopack-2@1.0.0
#  mongo@1.1.7
#  mrt:later@1.6.1

If you run the command below, you can see the value of:

"architecturesOS": [
    "os"
  ]

This indicates that the package has no platform specific dependencies that need native built components. This also hasn't changed between 1.4.0 and 1.5.x. My conclusion, if node-gyp is running while installing job-collection, meteor add is doing something very wrong.

meteor show --ejson vsivsi:job-collection@1.5.1

{                                             
  "exports": [
    {
      "name": "Job",
      "architectures": [
        "server",
        "web.browser",
        "web.cordova"
      ]
    },
    {
      "name": "JobCollection",
      "architectures": [
        "server",
        "web.browser",
        "web.cordova"
      ]
    }
  ],
  "implies": [],
  "dependencies": [
    {
      "name": "check",
      "constraint": "1.2.5",
      "weak": false
    },
    {
      "name": "coffeescript",
      "constraint": "1.12.3_1",
      "weak": false
    },
    {
      "name": "isobuild:isopack-2",
      "constraint": "1.0.0",
      "weak": false
    },
    {
      "name": "mongo",
      "constraint": "1.1.16",
      "weak": false
    },
    {
      "name": "mrt:later",
      "constraint": "1.6.1",
      "weak": false
    }
  ],
  "name": "vsivsi:job-collection",
  "version": "1.5.1",
  "description": "[![Build Status](https://travis-ci.org/vsivsi/meteor-job-collection.svg)](https://travis-ci.org/vsivsi/meteor-job-collection)",
  "summary": "A persistent and reactive job queue for Meteor, supporting distributed workers that can run anywhere",
  "git": "https://github.com/vsivsi/meteor-job-collection.git",
  "publishedBy": "vsivsi",
  "publishedOn": {
    "$date": 1493059588716
  },
  "installed": true,
  "architecturesOS": [
    "os"
  ]
}

[vsivsi]

And just a final note, when you ran meteor test-packages ./ on your local clone of the job-collection repo, meteor successfully built and executed job-collection on your platform. So, the problem clearly isn't that the package won't build/run on Windows 10.

[cormip]

Not sure if this is helpful or not, but here is the output with METEOR_PROFILE=1

D:\temp\emptyProj>set METEOR_PROFILE=1

D:\temp\emptyProj>meteor add vsivsi:job-collection
| (#1) Profiling: ProjectContext initializeCatalog
|
| ProjectContext initializeCatalog.................................13 ms (1)
| ├─ _readProjectMetadata                                           9 ms (1)
| └─ _initializeCatalog.............................................4 ms (1)
|    └─ LocalCatalog#initialize.....................................3 ms (1)
|       └─ addPatternsToList                                        2 ms (2)
|
| Top leaves:
|
| (#1) Total: 13 ms (ProjectContext initializeCatalog)
|
| (#2) Profiling: ProjectContext prepareProjectForBuild
   Loading vsivsi:job-collection@1.5.1...    |

[lmachens]

same problem here. any solution?

[vsivsi]

@lmachens I'm blocked by my inability to reproduce the problem. I'm not setup to support Windows. Based on what we know, I'm about 85% sure it's a Meteor issue, but debugging Meteor internal code on Windows is not a place I can go. If someone else wants to dig into it and can specifically point to an issue in job-collection, I"m happy to issue a fix (or even better accept a PR). But I'm pretty confident that this will end up in an issue for MDG to troubleshoot/resolve. Wish I had a better answer.

[lmachens]

Ok thx. 1.4.0 is working fine.

[ddaydd]

same

[lmachens]

It has to do something with atmosphere. The Package is working fine if I copy it my packages folder.

Maybe there is a problem with the git submodule of meteor-job?

[vsivsi]

Somebody should file an issue with the Meteor project on this. Since I can't reproduce it, It can't be me.

[lmachens]

Can you deploy a new version on athmosphere with a different tag? Maybe the problem is not related to your changes.

[vsivsi]

Two published versions on Atmosphere each have this same problem installing on Windows (1.5.0 and 1.5.1). Multiple people have now verified that these versions run fine on Windows if they are cloned out directly into the packages directory and installed manually. And of course, 1.4.x versions continue to work. My best guess is that something in Meteor changed between the 1.4.x releases and 1.5.x ones that messed up the Windows install behavior of some packages published thereafter. job-collection is a pretty vanilla package really, about the only thing exotic about it it that it has a git submodule (the meteor-job package).

Which was all a long winded way of saying that I don't think republishing the package to Atmosphere will change anything until the issue in Meteor is identified and resolved. It didn't make any difference between 1.5.0 and 1.5.1, so I don't know why it would now...

[tcastelli]

I have also found the problem, have you tried to open an issue on the official meteor repo? (For now i'm manually cloning the repo to packages)

[vsivsi]

Hi, just so you know, I'm about to drop off the internet for almost a month, so I won't be able to look into this until around June 20th. Sorry for any inconvenience.

[sdarnell]

My guess is that its related to the inclusion on fibers in the node_modules of this package. On macos (with meteor 1.6) I hit an issue where it was initially trying to recompile the embedded fibers and whilst it did eventually give up for me, it could be that on Windows it takes much longer or keeps trying for longer. See https://github.com/vsivsi/meteor-job-collection/issues/239

[vsivsi]

@sdarnell I don't think these are related. JobCollection versions 1.4.x and 1.5.x are identical w.r.t. the git submodule and its dev dependencies. 1.4.x installs fine from Atmosphere on Windows (under Meteor 1.4.x.x) and 1.5.x does not. But it does work if manually installed. None of this has anything to do with Meteor 1.5+ and the changes between JobCollection 1.4.x and 1.5.x are unlikely to have triggered such a problem. The main thing that changed was the version of Meteor that these versions of JobCollection were published with.

[gitTerebi]

I got the same issue too upgrading 1.5 to 1.5.1.

I noticed it was trying to update to vsivsi:job-collection@1.5.1, when the newest is 1.5.2!

I just opened the versions file and manually set the it to 1.5.2

Now it updates and loads the package correctly. Seems like Meteor screwed up the 1.5 -> 1.5.1 upgrade path.

[vsivsi]

I'm guessing that this issue is related to the issues with the Meteor 1.6 beta RCs on this thread:

https://github.com/vsivsi/meteor-job-collection/issues/239

Hopefully JC 1.5.2 fixes all of these issues.

[ujwal-setlur]

On OS X, an a very fresh meteor 1.7 project, when I do meteor add vsivsi:job-collection, I get version 1.4.0 instead of version 1.5.x