Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

i wanna install [ "ink" ] #294

Closed
PlumpMath opened this issue Apr 26, 2022 · 4 comments · Fixed by #302
Closed

i wanna install [ "ink" ] #294

PlumpMath opened this issue Apr 26, 2022 · 4 comments · Fixed by #302

Comments

@PlumpMath
Copy link

PlumpMath commented Apr 26, 2022

[ "react" ] works fine.
I haven't tested the rest, but I'm worried that there are many things that won't work.

``
error: builder for '/nix/store/alrsqfp0cqhf5im0j1h22q5gx9ll8jwq-ink-3.2.0.drv' failed with exit code 1;
last 10 log lines:
> npm WARN old lockfile at async fetch (/nix/store/gx91ndd69gm0q0rlcs2lm48kjfr91v7m-nodejs-16.14.2/lib/node_modules/npm/node_modules/make-fetch-happen/lib/fetch.js:98:7)
> npm WARN old lockfile at async Array. (/nix/store/gx91ndd69gm0q0rlcs2lm48kjfr91v7m-nodejs-16.14.2/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/build-ideal-tree.js:759:9) {
> npm WARN old lockfile code: 'ENOTCACHED'
> npm WARN old lockfile }
> npm ERR! code ENOTCACHEDsill idealTree buildDeps
> npm ERR! request to https://registry.npmjs.org/@sindresorhus%2ftsconfig failed: cache mode is 'only-if-cached' but no cached response is available.
>
> npm ERR! A complete log of this run can be found in:
> npm ERR! /private/tmp/nix-build-ink-3.2.0.drv-0/.npm/_logs/2022-04-26T22_12_10_054Z-debug-0.log
>
For full logs, run 'nix log /nix/store/alrsqfp0cqhf5im0j1h22q5gx9ll8jwq-ink-3.2.0.drv'.

@svanderburg
Copy link
Owner

I'm currently investigating the situation. What I already know is that for newer NPM versions (that work with lockfile version 2), sometimes information is missing, and as a result, NPM tries to fetch that missing information from the NPM registry. Since network access is restricted in regular Nix derivations, this will fail.

The v2 lockfile format is an hybrid between the v1 and v3 formats, because the latter is not backwards compatible.

The proper solution would be to also support v3 lock files, but providing this will not be an easy change.

It should still be possible to get a successful installation to bypass the NPM install step (see README.md for more information on how to do this).

@PlumpMath
Copy link
Author

PlumpMath commented May 16, 2022

I don't know what to do.
Could you please leave an example of installing the ink package by way of like your blog?
Even after reading the readme file, I didn't know where to start. y.g
I purposely split the nodePackages,
I'm thinking of merging it easily with buildInput .
Thanks.

@PlumpMath
Copy link
Author

@PlumpMath
Copy link
Author

The packages are now installed. However, it is not imported from node. I think I've been obsessed with something for the past few months. I need to know exactly where the problem was... As you said, did you downgrade the version again from the nodejs side? However, the current problem that is not called in repl seems to be a problem on the nix side. I returned to flake in the old legacy way, but I'll have to check where the node_modules folder is in flake.

lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 13, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 13, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 18, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 21, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 21, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 27, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 27, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 27, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 27, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 27, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants