Install seems to fail with iojs@3

[dominicbarnes]

I haven't confirmed 100% yet, but it looks like installing duo w/ iojs@3 breaks. I'm presuming some changes there have broken compiled modules (since we use leveldb internally for the cache)

I'm thinking about pinning our tests to iojs@2 for now, any thoughts @duojs/owners ?

[darsain]

I had some leveldb compilation failures when installing duo on windows before iojs@3. I worked around it (copied installed duo from node_modules of other project), and didn't give it much thought. I assumed it was the endless module dependency depth issue on windows that is being fixed in npm@3, but just tried to install duo on iojs@3 and got tons of errors, same as before, so I guess it wasn't that.

Errors thrown here. npm-debug.log is 1.3 MB. If you need it just tell me where to host it.

In my mind, the ideal fix would to remove/replace the leveldb dependency altogether. I think it was added only recently, as I don't remember npm install duo to be compiling stuff before, so shouldn't be much intertwined yet hopefully. leveldb makes each duo install very heavy, and it being a compiled module, it requires a painful additional steps to even install. And there are always some problems with these. At least on windows :(

Right now, looking at the error report, I have no idea whether this is:

• iojs issue
• npm too deep dependency paths on windows issue
• my visual studio environment is lacking something, or is installed kinda incorrectly (as it does compiles other stuff). I hope this is not it as I don't know what else to install/uninstall/reinstall. I already have a 7 GB VS installation sitting on my HDD and serving no other purpose than just to compile node modules.
• leveldb failing to be windows compatible by not caring about this platform, or having some bugs that make it not compile

This is so frustrating.

[dominicbarnes]

@darsain I added leveldb to give duo's caching system a huge overhaul. (which it badly needed because of huge performance problems the old system had, more details here) tl;dr: the main reason I chose to adopt it is to handle parallel reading/writing, particularly in processes handling multiple builds in parallel.

In a nutshell, I'm not willing to revert the caching back to what it was at this point, at least not without an as-good/better replacement. Sorry about adding complexity to the installation, but it's been a worthwhile tradeoff all things considered.

[dominicbarnes]

Fwiw, leveldb has windows on their list of supported platforms, and I've only started seeing problems once iojs@3 came out. Thus, my suspicion is that they had a breaking change to something compiled modules were depending on. (particularly since they did bump major)

My guess is this will be fixed by the leveldb team soon, but until they do we can just pin our test harness to iojs@2.

[RobLoach]

On Ubuntu 15.04, with iojs@3, it looks like leveldown installation fails:

  CXX(target) Release/obj.target/leveldown/src/batch.o
In file included from ../src/batch.cc:3:0:
../node_modules/nan/nan.h:261:25: error: redefinition of ‘template<class T> v8::Local<T> _NanEnsureLocal(v8::Local<T>)’
 NAN_INLINE v8::Local<T> _NanEnsureLocal(v8::Local<T> val) {
                         ^
../node_modules/nan/nan.h:256:25: note: ‘template<class T> v8::Local<T> _NanEnsureLocal(v8::Handle<T>)’ previously declared here
 NAN_INLINE v8::Local<T> _NanEnsureLocal(v8::Handle<T> val) {
                         ^
../node_modules/nan/nan.h:661:13: error: ‘node::smalloc’ has not been declared
     , node::smalloc::FreeCallback callback
             ^
../node_modules/nan/nan.h:661:35: error: expected ‘,’ or ‘...’ before ‘callback’
     , node::smalloc::FreeCallback callback
                                   ^
../node_modules/nan/nan.h: In function ‘v8::Local<v8::Object> NanNewBufferHandle(char*, size_t, int)’:
../node_modules/nan/nan.h:665:50: error: ‘callback’ was not declared in this scope
         v8::Isolate::GetCurrent(), data, length, callback, hint);
                                                  ^
../node_modules/nan/nan.h:665:60: error: ‘hint’ was not declared in this scope
         v8::Isolate::GetCurrent(), data, length, callback, hint);
                                                            ^
../node_modules/nan/nan.h: In function ‘v8::Local<v8::Object> NanNewBufferHandle(const char*, uint32_t)’:
../node_modules/nan/nan.h:672:67: error: call of overloaded ‘New(v8::Isolate*, const char*&, uint32_t&)’ is ambiguous
     return node::Buffer::New(v8::Isolate::GetCurrent(), data, size);
                                                                   ^
../node_modules/nan/nan.h:672:67: note: candidates are:
In file included from ../src/batch.cc:2:0:
/home/rob/.node-gyp/3.0.0/src/node_buffer.h:35:40: note: v8::MaybeLocal<v8::Object> node::Buffer::New(v8::Isolate*, v8::Handle<v8::String>, node::encoding) <near match>
 NODE_EXTERN v8::MaybeLocal<v8::Object> New(v8::Isolate* isolate,
                                        ^
/home/rob/.node-gyp/3.0.0/src/node_buffer.h:35:40: note:   no known conversion for argument 3 from ‘uint32_t {aka unsigned int}’ to ‘node::encoding’
/home/rob/.node-gyp/3.0.0/src/node_buffer.h:47:40: note: v8::MaybeLocal<v8::Object> node::Buffer::New(v8::Isolate*, char*, size_t) <near match>
 NODE_EXTERN v8::MaybeLocal<v8::Object> New(v8::Isolate* isolate,
                                        ^
/home/rob/.node-gyp/3.0.0/src/node_buffer.h:47:40: note:   no known conversion for argument 2 from ‘const char*’ to ‘char*’
In file included from ../src/batch.cc:3:0:
../node_modules/nan/nan.h: In function ‘v8::Local<v8::Object> NanNewBufferHandle(uint32_t)’:
../node_modules/nan/nan.h:676:61: error: could not convert ‘node::Buffer::New(v8::Isolate::GetCurrent(), ((size_t)size))’ from ‘v8::MaybeLocal<v8::Object>’ to ‘v8::Local<v8::Object>’
     return node::Buffer::New(v8::Isolate::GetCurrent(), size);
                                                             ^
../node_modules/nan/nan.h: In function ‘v8::Local<v8::Object> NanBufferUse(char*, uint32_t)’:
../node_modules/nan/nan.h:683:12: error: ‘Use’ is not a member of ‘node::Buffer’
     return node::Buffer::Use(v8::Isolate::GetCurrent(), data, size);
            ^
leveldown.target.mk:106: recipe for target 'Release/obj.target/leveldown/src/batch.o' failed
make: *** [Release/obj.target/leveldown/src/batch.o] Error 1
make: Leaving directory '/tmp/jstransformer-duo/node_modules/duo/node_modules/duo-cache/node_modules/level/node_modules/leveldown/build'
prebuild ERR! build `make` failed with exit code: 2

Some discussion is in the works over at https://github.com/Level/leveldown/issues/211 .

[micky2be]

The problem is node-gyp used by nan not being compatible with the v8 version used by iojs 3. The newest version of nan (2.x.x) is compatible with iojs 3. So need to track down the dependencies using an older version of nan and update it. Looks like there is only leveldown that use nan: duo-cache@2.1.2 --> level@1.3.0 --> level-packager@1.1.0 --> leveldown@1.4.0 --> nan@1.8.4

leveldown has been updated already on master, so just need to wait for releases of all the tree of dependencies.