Installation is (still) failing #2

bradenbest · 2018-04-30T21:18:12Z

So I've tried the following versions of node:

v9.0.0-pre - the original issue
v4.2.6 (via ubuntu repo) - too old, fails on a syntax error
v7.10 - reasonably recent seeming version (people have reported 7.x working on forums back in 2017 IIRC) -- npm says it "doesn't support" this version and crashes
v10.0.0 - the latest version of node, fails like so:

--

 $ node --version
 10.0.0
 $ sudo npm i leveldb-editor
 > leveldown@1.7.2 install /home/braden/node_modules/leveldown
 > prebuild-install || node-gyp rebuild

 prebuild-install WARN install No prebuilt binaries found (target=10.0.0 runtime=node arch=x64 platform=linux)
 gyp ERR! configure error
 gyp ERR! stack Error: EACCES: permission denied, mkdir 
 '/home/braden/node_modules/leveldown/build'
 gyp ERR! System Linux 4.4.0-112-generic
 gyp ERR! command "/home/braden/code/dist/node/10.0.0/node-v10.0.0-linux-x64/bin/node" 
 "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
 gyp ERR! cwd /home/braden/node_modules/leveldown
 gyp ERR! node -v v10.0.0
 gyp ERR! node-gyp -v v3.6.2
 gyp ERR! not ok
 npm WARN enoent ENOENT: no such file or directory, open '/home/braden/package.json'
 npm WARN braden No description
 npm WARN braden No repository field.
 npm WARN braden No README data
 npm WARN braden No license field.
 
 npm ERR! code ELIFECYCLE
 npm ERR! errno 1
 npm ERR! leveldown@1.7.2 install: `prebuild-install || node-gyp rebuild`
 npm ERR! Exit status 1
 npm ERR!
 npm ERR! Failed at the leveldown@1.7.2 install script.
 npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
 
 npm ERR! A complete log of this run can be found in:
 npm ERR!     /home/braden/.npm/_logs/2018-04-30T21_07_55_316Z-debug.log

Looks similar to the failure from v9.0.0-pre

I don't think it's reasonable to have to try four different versions of node and have them all fail. Further, I can't find any information on what version level does support. Why isn't this information on the README.md of this project?

This is actually worse than trying to install a project on a system with both python2 and 3. I have never seen dependency hell this bad in a package manager what's sole purpose is to avoid dependency hell

The text was updated successfully, but these errors were encountered:

bradenbest · 2018-04-30T21:31:23Z

Let's simplify this a bit. What versions of node and npm are you using? And are you still able to successfully install this package with them? Or does it crash for you, too?

derhuerst · 2018-04-30T22:48:41Z

Looks similar to the failure from v9.0.0-pre

Nope, it's a different error.

stack Error: EACCES: permission denied, mkdir '/home/braden/node_modules/leveldown/build'

This is the relevant line. The user you're executing npm with doesn't have write access to /home/braden/node_modules, the install directory.

I don't think it's reasonable to have to try four different versions of node and have them all fail.

Using -pre versions is pretty uncommon in the Node ecosystem and AFAIK not encouraged. Node 4 is outdated and out of support by now. Node 7 is very outdated. See also the LTS schedule.

This is actually worse than trying to install a project on a system with both python2 and 3. I have never seen dependency hell this bad in a package manager what's sole purpose is to avoid dependency hell

Your judgement is inaccurate.

In fact, in many Node projects, many of the complaints about failing installs are because of outdated Node versions shipping with distros. Check request/request#2772 for a lengthy discussion on this. I personally use the NodeSource package sources on Linux.

Secondly, the term dependendy hell actually refers to a different term than what you are talking about.

derhuerst · 2018-04-30T22:52:33Z

Let's simplify this a bit. What versions of node and npm are you using? And are you still able to successfully install this package with them? Or does it crash for you, too?

I comes down to getting native builds to work. LevelDB is native code and therefore it's wrapping Node library leveldown compiles on install. There are also prebuild binaries for it (installed using prebuild-install), but not for every os/node version pair. You get the "No prebuilt binaries found" warning above, because it could find a matching prebuilt binary and will try to compile from source.

If you get the leveldown/level npm package to build on your machine, leveldb-editor should work with every Node version it specifies to work with (npm will warn you about incompatible versions).

bradenbest · 2018-05-01T00:16:01Z

@derhuerst

This is the relevant line. The user you're executing npm with doesn't have write access to /home/braden/node_modules, the install directory.

How is this possible? Not only did I run the command as root, but take a look:

$ stat /home/braden/node_modules
  File: '/home/braden/node_modules'
  Size: 4096            Blocks: 8          IO Block: 4096    directory
Device: 821h/2081d      Inode: 50855937    Links: 41
Access: (0775/drwxrwxr-x)  Uid: ( 1000/  braden)   Gid: ( 1000/  braden)
Access: 2018-04-30 16:26:29.931377151 -0600
Modify: 2018-04-30 16:30:03.165234204 -0600
Change: 2018-04-30 16:30:03.165234204 -0600
 Birth: -

There is clearly nothing wrong with the directory. It exists, is owned by me, and has full read write permissions.

However, I just tried a run without sudo and this happened:

$ node -v
10.0.0
$ npm i leveldb-editor
> leveldown@1.7.2 install /home/braden/node_modules/level/node_modules/leveldown
> prebuild-install || node-gyp rebuild

prebuild-install WARN install No prebuilt binaries found (target=10.0.0 runtime=node arch=x64 platform=linux)
make: Entering directory '/home/braden/node_modules/level/node_modules/leveldown/build'
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/db/builder.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/db/db_impl.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/db/db_iter.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/db/filename.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/db/dbformat.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/db/log_reader.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/db/log_writer.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/db/memtable.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/db/repair.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/db/table_cache.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/db/version_edit.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/db/version_set.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/db/write_batch.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/helpers/memenv/memenv.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/port/port_posix_sse.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/table/block.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/table/block_builder.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/table/filter_block.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/table/format.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/table/iterator.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/table/merger.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/table/table.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/table/table_builder.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/table/two_level_iterator.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/util/arena.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/util/bloom.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/util/cache.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/util/coding.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/util/comparator.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/util/crc32c.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/util/env.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/util/filter_policy.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/util/hash.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/util/logging.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/util/options.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/util/status.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/port/port_posix.o
  CXX(target) Release/obj.target/leveldb/deps/leveldb/leveldb-1.20/util/env_posix.o
  AR(target) Release/obj.target/deps/leveldb/leveldb.a
  COPY Release/leveldb.a
  CXX(target) Release/obj.target/snappy/deps/snappy/snappy-1.1.4/snappy-sinksource.o
  CXX(target) Release/obj.target/snappy/deps/snappy/snappy-1.1.4/snappy-stubs-internal.o
  CXX(target) Release/obj.target/snappy/deps/snappy/snappy-1.1.4/snappy.o
  AR(target) Release/obj.target/deps/snappy/snappy.a
  COPY Release/snappy.a
  CXX(target) Release/obj.target/leveldown/src/batch.o
In file included from ../../nan/nan.h:192:0,
                 from ../src/batch.cc:3:
../../nan/nan_maybe_43_inl.h: In function ‘Nan::Maybe<bool> Nan::ForceSet(v8::Local<v8::Object>, v8::Local<v8::Value>, v8::Local<v8::Value>, v8::PropertyAttribute)’:
../../nan/nan_maybe_43_inl.h:112:15: error: ‘class v8::Object’ has no member named ‘ForceSet’
   return obj->ForceSet(isolate->GetCurrentContext(), key, value, attribs);
               ^
In file included from ../src/batch.cc:3:0:
../../nan/nan.h: In function ‘v8::Local<v8::Value> Nan::MakeCallback(v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*)’:
../../nan/nan.h:835:60: warning: ‘v8::Local<v8::Value> node::MakeCallback(v8::Isolate*, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*)’ is deprecated: Use MakeCallback(..., async_context) [-Wdeprecated-declarations]
         v8::Isolate::GetCurrent(), target, func, argc, argv);
                                                            ^
In file included from ../src/batch.cc:1:0:
/home/braden/.node-gyp/10.0.0/include/node/node.h:172:50: note: declared here
                 NODE_EXTERN v8::Local<v8::Value> MakeCallback(
                                                  ^
/home/braden/.node-gyp/10.0.0/include/node/node.h:88:42: note: in definition of macro ‘NODE_DEPRECATED’
     __attribute__((deprecated(message))) declarator
                                          ^
In file included from ../src/batch.cc:3:0:
../../nan/nan.h: In function ‘v8::Local<v8::Value> Nan::MakeCallback(v8::Local<v8::Object>, v8::Local<v8::String>, int, v8::Local<v8::Value>*)’:
../../nan/nan.h:850:62: warning: ‘v8::Local<v8::Value> node::MakeCallback(v8::Isolate*, v8::Local<v8::Object>, v8::Local<v8::String>, int, v8::Local<v8::Value>*)’ is deprecated: Use MakeCallback(..., async_context) [-Wdeprecated-declarations]
         v8::Isolate::GetCurrent(), target, symbol, argc, argv);
                                                              ^
In file included from ../src/batch.cc:1:0:
/home/braden/.node-gyp/10.0.0/include/node/node.h:165:50: note: declared here
                 NODE_EXTERN v8::Local<v8::Value> MakeCallback(
                                                  ^
/home/braden/.node-gyp/10.0.0/include/node/node.h:88:42: note: in definition of macro ‘NODE_DEPRECATED’
     __attribute__((deprecated(message))) declarator
                                          ^
In file included from ../src/batch.cc:3:0:
../../nan/nan.h: In function ‘v8::Local<v8::Value> Nan::MakeCallback(v8::Local<v8::Object>, const char*, int, v8::Local<v8::Value>*)’:
../../nan/nan.h:865:62: warning: ‘v8::Local<v8::Value> node::MakeCallback(v8::Isolate*, v8::Local<v8::Object>, const char*, int, v8::Local<v8::Value>*)’ is deprecated: Use MakeCallback(..., async_context) [-Wdeprecated-declarations]
         v8::Isolate::GetCurrent(), target, method, argc, argv);
                                                              ^
In file included from ../src/batch.cc:1:0:
/home/braden/.node-gyp/10.0.0/include/node/node.h:158:50: note: declared here
                 NODE_EXTERN v8::Local<v8::Value> MakeCallback(
                                                  ^
/home/braden/.node-gyp/10.0.0/include/node/node.h:88:42: note: in definition of macro ‘NODE_DEPRECATED’
     __attribute__((deprecated(message))) declarator
                                          ^
In file included from ../src/batch.cc:3:0:
../../nan/nan.h: In member function ‘v8::Local<v8::Value> Nan::Callback::Call_(v8::Isolate*, v8::Local<v8::Object>, int, v8::Local<v8::Value>*) const’:
../../nan/nan.h:1479:5: warning: ‘v8::Local<v8::Value> node::MakeCallback(v8::Isolate*, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*)’ is deprecated: Use MakeCallback(..., async_context) [-Wdeprecated-declarations]
     ));
     ^
In file included from ../src/batch.cc:1:0:
/home/braden/.node-gyp/10.0.0/include/node/node.h:172:50: note: declared here
                 NODE_EXTERN v8::Local<v8::Value> MakeCallback(
                                                  ^
/home/braden/.node-gyp/10.0.0/include/node/node.h:88:42: note: in definition of macro ‘NODE_DEPRECATED’
     __attribute__((deprecated(message))) declarator
                                          ^
leveldown.target.mk:113: recipe for target 'Release/obj.target/leveldown/src/batch.o' failed
make: *** [Release/obj.target/leveldown/src/batch.o] Error 1
make: Leaving directory '/home/braden/node_modules/level/node_modules/leveldown/build'
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:258:23)
gyp ERR! stack     at ChildProcess.emit (events.js:182:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:225:12)
gyp ERR! System Linux 4.4.0-112-generic
gyp ERR! command "/home/braden/code/dist/node/10.0.0/node-v10.0.0-linux-x64/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/braden/node_modules/level/node_modules/leveldown
gyp ERR! node -v v10.0.0
gyp ERR! node-gyp -v v3.6.2
gyp ERR! not ok
npm WARN enoent ENOENT: no such file or directory, open '/home/braden/package.json'
npm WARN braden No description
npm WARN braden No repository field.
npm WARN braden No README data
npm WARN braden No license field.

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! leveldown@1.7.2 install: `prebuild-install || node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the leveldown@1.7.2 install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/braden/.npm/_logs/2018-05-01T00_09_03_432Z-debug.log

So not only does the compile fail due to errors in the source code, but it's saying something about ~/package.json. There is no such file in my home directory, and I don't see why it expects there to be said file in my home directory. If there was a file at some point, I must have deleted it after inspecting it, finding it to be empty and/or devoid of important information.

Thoughts?

derhuerst · 2018-05-01T00:55:24Z

There is clearly nothing wrong with the directory. It exists, is owned by me, and has full read write permissions.

However, I just tried a run without sudo and this happened:

Interesting. Other possible reasons that come to my mind: Maybe there are ACLs on the directory? The mkdir called by npm on installation should work exactly like a regular shell mkdir.

So not only does the compile fail due to errors in the source code, but it's saying something about ~/package.json.

You can ignore this (it has a WARN in front indicating that it's only a warning). This is being shown because you're trying to install leveldb-editor locally, which you would usually do in a project containing a package.json.

derhuerst · 2018-05-01T00:57:16Z

The leveldown build now during the compile phase. This is something out of my hands, I'm just using it as a dependency.

We can try one thing though: I will upgrade it to the latest version so we can have a look if the leveldown maintainers magically™️ resolved these build issues.

derhuerst · 2018-05-01T01:01:56Z

Please try again with leveldb-editor@0.1.2.

derhuerst · 2018-05-01T01:02:29Z

btw what are you trying to do with this tool? are you aware that it is really basic, hacked together quickly?

bradenbest · 2018-05-01T01:12:35Z

Please try again with leveldb-editor@0.1.2

No luck

$ sudo npm i -g leveldg-editor@0.1.2
(some stuff)
> prebuild-install || node-gyp rebuild

prebuild-install WARN install EACCES: permission denied, mkdir 
'/home/braden/code/dist/node/10.0.0/node-v10.0.0-linux-x64/lib/node_modules/leveldb-editor/node_modules/leveldown/build'
gyp ERR! configure error
gyp ERR! stack Error: EACCES: permission denied, mkdir '/home/braden/code/dist/node/10.0.0/node- v10.0.0-linux-x64/lib/node_modules/leveldb-editor/node_modules/leveldown/build'
gyp ERR! System Linux 4.4.0-112-generic
gyp ERR! command "/home/braden/code/dist/node/10.0.0/node-v10.0.0-linux-x64/bin/node" 
"/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/braden/code/dist/node/10.0.0/node-v10.0.0-linux-x64/lib/node_modules/leveldb- editor/node_modules/leveldown
gyp ERR! node -v v10.0.0
gyp ERR! node-gyp -v v3.6.2
gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! leveldown@3.0.1 install: `prebuild-install || node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the leveldown@3.0.1 install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/braden/.npm/_logs/2018-05-01T01_06_27_177Z-debug.log

btw what are you trying to do with this tool?

I'm trying to transfer save data from the browser version of a game to its desktop version. After some investigation, I uncovered that the game was using indexeddb, so I used locate to find where it was, and then by inspecting the files, found that 000003.log contains the data, but it's in a strange binary format. After much research, I eventually stumbled across a post asking about a file named "000003.log", and learned that the format is apparently leveldb. I'm unwilling to learn how to use indexeddb / Google's format for it, so Google led me here. I'm fully aware that even if I get it to work, it's a total crap shoot. Needless to say, this isn't the only thing that's been breaking on me today, and I've wasted the whole day trying to fix these things, so it's been a shitty day for me, hence why I've been harassing you on the issues. Yeah. Sorry about that.

bradenbest · 2018-05-01T01:17:39Z

The irony is that now the itch client has broken on me as well, so even if I transfer the data, I can't even play the game on the desktop, so this was all for nothing. 10 hours of I.T. nightmare for nothing. Yeah. A new update makes itch depend on some stupid package called dependency butler. The problem is, well, aside from the blatant NIH-syndrome itch-dev seems to be suffering from, that it won't even download, and they didn't even think to put this process in the background so you could actually use the software. I'm just fucking speechless.

I'm probably wrong about what's wrong with it, too. All I know is that this is the first time I've seen this dependency butler shit show up, and the app won't work any more because it hangs on that screen for eternity.

derhuerst · 2018-05-01T09:17:23Z

Pay attention to the error. This is the permission error you've had before.

$ sudo npm i -g leveldg-editor@0.1.2
[...]
prebuild-install WARN install EACCES: permission denied, mkdir '/home/braden/code/dist/node/10.0.0/node-v10.0.0-linux-x64/lib/node_modules/leveldb-editor/node_modules/leveldown/build'

Again, try to fix the permissions of your node_modules directories. Note that you've tried both local install and global install, which work in different directories. This may be why it seems like an undebuggable mess.

I will try to sum it up:

Make sure you have a recent Node (10 or 8) and a recent npm (5 or 6).
Wipe your install directory and recreate it with proper permissions. For local install, this is basically ./node_modules. For global install, it depends on your env variables, but your logs above show /home/braden/code/dist/node/10.0.0/node-v10.0.0-linux-x64/lib/node_modules.
Install any other tool that doesn't compile native code on install. E.g. install npm i -g parse-url-cli and if it works with parse-url 'example.org:2000'. If this step fails, your npm setup is borked and it's clearly not about leveldb-editor or leveldown.
Install leveldb-editor.

You may instead want to try npx. It comes bundled with recent npm versions. I installs whatever you're trying to run into a temp dir, runs it, and clears the directory. It still needs proper permissions on the install dir though.

I'm trying to transfer save data from the browser version of a game to its desktop version. [...] After much research, I eventually stumbled across a post asking about a file named "000003.log", and learned that the format is apparently leveldb. I'm unwilling to learn how to use indexeddb / Google's format for it, so Google led me here.

As much as I'm willing to show you that the common Node-based tool can be installed easily (and that most of the fuckups are related to permissions or outdated Node versions), this can be solved more practically:

Why don't you use the LevelDB library of your favourite language? With a quick search I've found some for Python, for Go (and another), for Rust and the plain C++ lib.

bradenbest · 2018-05-02T05:53:37Z

@derhuerst Huh. I thought deleting ~/node_modules would erase all of my other node programs, but I guess that's not the case. Deleting the directory and attempting again, without first re-installing npm locally, worked.

That said, trying to install it globally (sudo npm i -g) still fails with an ELIFECYCLE error at the end, and at this point, I'm over it. It works with a local install or an invocation of npx.

On an unrelated note, the program crashes when I try to open a database. I'll post a separate issue for that. I'll leave whether or not to close this issue up to you, but urge you to keep in mind how difficult a time I had getting it to work, and maybe put some information in the readme's installation section that addresses this. Because I will say that my first attempt to install followed the guide to the letter (sudo=yes). And evidently, the install failed because I was using v9.0.0-pre, but without a way to know which version is the compatible from the installation instructions (It'd've failed if I used the repo's 4.x build, too), it's not that obvious. I may be very experienced with JavaScript as used in the browser, but I rarely ever use npm, and expecting me to know to look in package.json to find that information, in my opinion, is a fair bit unrealistic. I can only imagine the layman's viewpoint to be similar. Ubuntu is, after all, the most popular Linux distro out there, and for good reason, with the proprietary driver support and the bloody huge, long-term support software repository focused on curated stability. It's not that I don't like Arch Linux, it's just that I'm too lazy to go through the installation process, learn the new UEFI shit (yes, UEFI is still "new" to me) so the OS can actually boot, and maintain a rolling release. That's pretty much one of the major reasons why I haven't dropped Ubuntu for it. Well, that and drivers.

So to sum up, so it doesn't sound like I'm ranting at you, I think you should consider putting a notice in the installation instructions mentioning the node and npm versions a user should be using, because if the user is on ubuntu (or another distro with an outdated nodejs package), they are most likely going to also experience a failed install just as I did. Unless I'm wrong and node auto updates itself and I just got fucked over because I happened to be in an obscure edge case of users who installed an unusual version on of node their own.

Okay maybe I am ranting. Anyways, I'll see you on the other issue.

derhuerst · 2018-05-02T10:48:34Z

I thought deleting ~/node_modules would erase all of my other node programs, but I guess that's not the case.

Depends on how you installed all of those other tools. Read up on how npm installs things.

Deleting the directory and attempting again, without first re-installing npm locally, worked.

Great!

Because I will say that my first attempt to install followed the guide to the letter (sudo=yes).

I should probably delete this from the readme. People complain in this case as well, but it messes up with the system less.

And evidently, the install failed because I was using v9.0.0-pre, but without a way to know which version is the compatible from the installation instructions (It'd've failed if I used the repo's 4.x build, too), it's not that obvious. I may be very experienced with JavaScript as used in the browser, but I rarely ever use npm, and expecting me to know to look in package.json to find that information, in my opinion, is a fair bit unrealistic.

As I said, it's very very uncommon in the Node ecosystem to use pre- versions (some people do, but then on purpose). Regarding Node 4: npm would have printed a warning about incompatibility, since leveldb-editor says it's only compatible with Node 6+.

I can only imagine the layman's viewpoint to be similar. Ubuntu is, after all, the most popular Linux distro out there, and for good reason, with the proprietary driver support and the bloody huge, long-term support software repository focused on curated stability.

As I said before:

In fact, in many Node projects, many of the complaints about failing installs are because of outdated Node versions shipping with distros. Check request/request#2772 for a lengthy discussion on this.

So to sum up, so it doesn't sound like I'm ranting at you, I think you should consider putting a notice in the installation instructions mentioning the node and npm versions a user should be using, because if the user is on ubuntu (or another distro with an outdated nodejs package), they are most likely going to also experience a failed install just as I did.

Every Node project would have to do this, just because Ubuntu (or Debian actually) decided not to ship recent Node versions. This is not the proper place to address the problem. Also, as I said above: npm prints a warning about incompatible Node versions.

A more general point: I've hacked this project together in 8 commits in about an hour, back in August. Since then, I haven't touched it until now. It is a small tool I've written for myself, not a polished tool that promises to be usable for everyone; In fact, it probably has a few bugs.

While I have the motivation to keep my projects as working-out-of-the-box and beginner-friendly as possible, I simply can't to this for all of them. I usually try to document the basic stuff and hope that people will complain if something doesn't work, so I can fix it or help them.

In this specific case, a few issues came together:

The project is small and barely documented. The sudo in the readme is somewhat misleading.
It uses native code, which notoriously fails to compile on Linux distros because of missing/outdated libs.
You first used a pre Node version, then an outdated one (Not blaming you! How should you know?).
The code has a bug (UnhandledPromiseRejectionWarning + traceback when trying to open a database #3).

derhuerst added the question label Apr 30, 2018

bradenbest mentioned this issue May 2, 2018

UnhandledPromiseRejectionWarning + traceback when trying to open a database #3

Closed

derhuerst closed this as completed May 2, 2018

bradenbest mentioned this issue May 2, 2018

Identifier 'noop' has already been declared / exit 1 #4

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Installation is (still) failing #2

Installation is (still) failing #2

bradenbest commented Apr 30, 2018 •

edited

bradenbest commented Apr 30, 2018

derhuerst commented Apr 30, 2018

derhuerst commented Apr 30, 2018 •

edited

bradenbest commented May 1, 2018 •

edited

derhuerst commented May 1, 2018

derhuerst commented May 1, 2018

derhuerst commented May 1, 2018

derhuerst commented May 1, 2018

bradenbest commented May 1, 2018 •

edited

bradenbest commented May 1, 2018 •

edited

derhuerst commented May 1, 2018

bradenbest commented May 2, 2018 •

edited

derhuerst commented May 2, 2018

Installation is (still) failing #2

Installation is (still) failing #2

Comments

bradenbest commented Apr 30, 2018 • edited

bradenbest commented Apr 30, 2018

derhuerst commented Apr 30, 2018

derhuerst commented Apr 30, 2018 • edited

bradenbest commented May 1, 2018 • edited

derhuerst commented May 1, 2018

derhuerst commented May 1, 2018

derhuerst commented May 1, 2018

derhuerst commented May 1, 2018

bradenbest commented May 1, 2018 • edited

bradenbest commented May 1, 2018 • edited

derhuerst commented May 1, 2018

bradenbest commented May 2, 2018 • edited

derhuerst commented May 2, 2018

bradenbest commented Apr 30, 2018 •

edited

derhuerst commented Apr 30, 2018 •

edited

bradenbest commented May 1, 2018 •

edited

bradenbest commented May 1, 2018 •

edited

bradenbest commented May 1, 2018 •

edited

bradenbest commented May 2, 2018 •

edited