| 30 Jul 2023 |
 Lily Foster | (to clarify, it tries to pull the package name from IFD otherwise) | 01:11:11 |
| Lily Foster | Tbh you can probably get by without yarn2nix at all, though, if you are already having to override phases | 01:11:19 |
| Lily Foster | There's a few packages that use yarn --offline with fetchYarnDeps and don't use mkYarnPackage at all | 01:11:39 |
| Lily Foster | * There's a few packages that use yarn --offline install with fetchYarnDeps and don't use mkYarnPackage at all | 01:11:43 |
 gdamjan | what was IFD again? | 01:13:37 |
| Lily Foster | Import-from-derivation | 01:13:55 |
| Lily Foster | When you try to builtins.readFile or import from the result of a derivation (like a fetched FOD) | 01:14:13 |
 hexa | when one derivation needs to wait for the result of another derivation | 01:14:14 |
| hexa | something that's explicitly disabled on hydra | 01:14:23 |
| hexa | there are a few more functions that import under the hood https://nixos.wiki/wiki/Import_From_Derivation#Recognizing_IFD | 01:15:14 |
| hexa | it will work for you locally, and that's what makes it tricky 🙂 | 01:17:36 |
| gdamjan | heh | 01:17:44 |
| gdamjan | ok. let me try again the stdenv.mkDerivation path then | 01:19:57 |
| Lily Foster | In reply to @hexa:lossy.network
it will work for you locally, and that's what makes it tricky 🙂 I mean, it won't work for you locally anymore if you add --no-allow-import-from-derivation to the nix command (which is just what ofborg does iirc) | 02:27:20 |
| gdamjan | In reply to @gdamjan:spodeli.org
ok. let me try again the stdenv.mkDerivation path then https://gist.github.com/gdamjan/08901abe49baadf083034e93ed32ccbe#file-default-2-nix
I have no idea how kosher this is ^ | 03:09:48 |
| gdamjan | (ignore that I use my fork, that was to prune some additional deps) | 03:10:17 |
| gdamjan | but yarnLock = "${src}/yarn.lock"; would still be a problem, no?
so I need to take yarn.lock and add it to nixpkgs ? | 03:11:17 |
| gdamjan | going to sleep now ... see ya tomorrow | 03:13:06 |
| gdamjan | that's this change https://github.com/matrix-org/matrix-appservice-irc/pull/1758 | 03:13:59 |
| Lily Foster | In reply to @gdamjan:spodeli.org
but yarnLock = "${src}/yarn.lock"; would still be a problem, no?
so I need to take yarn.lock and add it to nixpkgs ? Not for fetchYarnDeps because it doesn't use the path at eval time (no import or read or anything), it's only used build time | 03:15:17 |
| Lily Foster | In reply to @gdamjan:spodeli.org
going to sleep now ... see ya tomorrow Rest well 💤 | 03:15:43 |
 dotlambda | How can I figure out which dependency causes
thread '<unnamed>' panicked at 'non-git dependencies should have assosciated integrity', src/parse/mod.rs:142:22
in https://github.com/karma-runner/karma ?
| 05:02:43 |
| dotlambda | * How can I figure out which dependency causes
thread '<unnamed>' panicked at 'non-git dependencies should have assosciated integrity', src/parse/mod.rs:142:22
when packaging https://github.com/karma-runner/karma using buildNpmPackage?
| 05:05:29 |
| dotlambda | turns out it's due to this line in package.json:
{
"devDependencies": {
"karma": "."
}
}
| 06:04:42 |
|  h7x4 joined the room. | 08:30:48 |
| Lily Foster | In reply to @robert:funklause.de
turns out it's due to this line in package.json:
{
"devDependencies": {
"karma": "."
}
}
Oh hmm, I can probably make that work if npm allows that, but does npm really allow using a package as a dev dependency of itself? | 10:50:19 |
| gdamjan | npm - everything goes | 10:50:55 |
| gdamjan | what's even the point of that | 10:51:12 |
| Lily Foster | In reply to @gdamjan:spodeli.org
what's even the point of that I think given it's a test runner that it's probably to allow them to run their own tests with itself | 10:53:22 |
| Lily Foster | But I imagine that would really only work when there are no lifecycle scripts that need to run to build the package (e.g. to run typescript compiler or something) | 10:54:27 |
