Description
This is not actually a problem in duckdb-node, but it puzzled me for a while and may explain some other bugs. So I'll document it here. Feel free to close this as wont-fix.
When I try to install with npm install duckdb, it errors out part way through with a message that includes the following:
685 error [log] GET https://npm.duckdb.org/duckdb/duckdb-v1.2.1-node-v109-linux-x64.tar.gz
685 error [error] install response status 403 Forbidden on https://npm.duckdb.org/duckdb/duckdb-v1.2.1-node-v109-linux-x64.tar.gz
and, later,
685 error Traceback (most recent call last):
685 error File "/usr/share/nodejs/node-gyp/gyp/gyp_main.py", line 33, in <module>
685 error sys.exit(load_entry_point('gyp==0.1', 'console_scripts', 'gyp')())
685 error File "/usr/share/nodejs/node-gyp/gyp/gyp_main.py", line 22, in importlib_load_entry_point
685 error for entry_point in distribution(dist_name).entry_points
685 error File "/home/rschroll/miniconda3/lib/python3.9/importlib/metadata.py", line 524, in distribution
685 error return Distribution.from_name(distribution_name)
685 error File "/home/rschroll/miniconda3/lib/python3.9/importlib/metadata.py", line 187, in from_name
685 error raise PackageNotFoundError(name)
685 error importlib.metadata.PackageNotFoundError: gyp
(Full log here: 2025-05-05T20_32_36_966Z-debug-0.log)
This seems to be due to two problems:
1. Ubuntu 24.04 sets the wrong node.js ABI version
Ubuntu 24.04 has node 18.19.1 installed. This should have ABI v108 (https://github.com/nodejs/node/blob/HEAD/doc/abi_version_registry.json#L32). However, it reports v109. This is a known problem (https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/2085804), but it doesn't look like they're planning on fixing this.
This means that when gyp looks for a precompiled binary, it looks for duckdb-v1.2.1-node-v109-linux-x64.tar.gz. However, the binary for node 18.* is duckdb-v1.2.1-node-v108-linux-x64.tar.gz. The server responds to this "not found" situation with a 403 error, which I can only assume is due to some weird off-by-one condition.
Ideally, gyp would build the binary from source, but....
2. gyp fails with a custom Python installation
As you may notice from the logs, my default python is not the system Python but a miniconda install. The gyp script does try to run under the system Python (judging from the shebang line), but evidently it finds itself using miniconda packages (as seen in the traceback).
To test this, I disabled my miniconda install, so that my system Python was the default. Installing in this environment has started building the binary.
Impact
I suspect this could be the cause of some of the problems in #95. The original problem is different, but some later comments do show the ABI version problem.
Possibly this could be fixed by hosting a v109 file binary that is the same as the v108. It's not clear to me whether Ubuntu actually changed the ABI or just bumped the version for no good reason.
As I said before, this is not really a duckdb issue. It's a Ubuntu package bug plus some disagreement between gyp and my Python installation. But since at least one other person seems to have hit this, I thought it was worth documenting.