| 10 Oct 2021 |
 balsoft | So I'm looking for those in crate2nix | 16:49:38 |
| balsoft | Interestingly, once it has been built once using older nix it then works with newer nix | 16:50:48 |
| balsoft | Although I guess this is down to flake caching | 16:50:54 |
| balsoft | Yes | 16:51:35 |
| balsoft | Here's the trace
error: store path '/nix/store/d0vm5k50fa9d6cjlch6s9cw61gn80xds-himalaya-crate2nix' is not allowed to have references
… while adding path '/nix/store/d0vm5k50fa9d6cjlch6s9cw61gn80xds-himalaya-crate2nix/crate'
at /nix/store/v316zxg1w7x8343xs9lmhkh5hvjmprsq-source/lib/sources.nix:240:17:
239| inherit origSrc filter name;
240| outPath = builtins.path { inherit filter name; path = origSrc; };
| ^
241| };
… while evaluating the attribute 'src' of the derivation 'rust_himalaya-0.4.0'
at /nix/store/v316zxg1w7x8343xs9lmhkh5hvjmprsq-source/pkgs/stdenv/generic/make-derivation.nix:203:11:
202| // (lib.optionalAttrs (attrs ? name || (attrs ? pname && attrs ? version)) {
203| name =
| ^
204| let
| 16:51:45 |
 tomberek | Yeah. Caching is great??? But with a cleared cache and gc’ing the paths, should be able to remake the problem. Perhaps use “path” in the minimal example. | 16:52:24 |
| balsoft | In reply to @tomberek:matrix.org
Yeah. Caching is great??? But with a cleared cache and gc’ing the paths, should be able to remake the problem. Perhaps use “path” in the minimal example. Yeah with --no-eval-cache it fails successfully :D | 16:53:02 |
| balsoft | Oh, hm, interesting. I wonder why it knows that derivation name | 16:53:51 |
| balsoft | Even more interesting is that it tries to add only one directory, crate | 16:55:03 |
| balsoft | * Even more interesting is that it tries to add only one subdirectory, crate | 16:55:06 |
| balsoft | In reply to @balsoft:balsoft.ru
Here's the trace
error: store path '/nix/store/d0vm5k50fa9d6cjlch6s9cw61gn80xds-himalaya-crate2nix' is not allowed to have references
… while adding path '/nix/store/d0vm5k50fa9d6cjlch6s9cw61gn80xds-himalaya-crate2nix/crate'
at /nix/store/v316zxg1w7x8343xs9lmhkh5hvjmprsq-source/lib/sources.nix:240:17:
239| inherit origSrc filter name;
240| outPath = builtins.path { inherit filter name; path = origSrc; };
| ^
241| };
… while evaluating the attribute 'src' of the derivation 'rust_himalaya-0.4.0'
at /nix/store/v316zxg1w7x8343xs9lmhkh5hvjmprsq-source/pkgs/stdenv/generic/make-derivation.nix:203:11:
202| // (lib.optionalAttrs (attrs ? name || (attrs ? pname && attrs ? version)) {
203| name =
| ^
204| let
Ok, I actually looked at the trace now | 16:56:30 |
| balsoft | The derivation which we import via IFD is using cleanSourceWith | 16:57:45 |
| balsoft | So, I suppose, it takes issue with the fact that we're using builtins.path on a derivation output? | 16:59:49 |
| balsoft | But then why how and why did it work before? | 17:00:06 |
| tomberek | Before the check was if the context was empty. Now it is if the path has references. So we have a path with no context, but with references? | 17:06:46 |
| balsoft | Yeah, I have confirmed that the context is indeed empty | 19:04:16 |
| balsoft | And yet there are references | 19:04:18 |
| tomberek | So it’s all working as expected via the logic in that commit. Is that the wrong logic? How can we fix it? Check if references are already allowed? | 19:45:34 |
| balsoft | I guess I'll try just not checking for references :D | 20:23:02 |
| balsoft | It seemed to work before... | 20:23:06 |
| balsoft | Yeah it evals and builds fine | 20:23:22 |
| tomberek | Well. You may be getting lucky that the references exist in your store already. It’s possible that can result in dangling references. | 22:05:57 |
| balsoft | That's true | 22:06:12 |
| balsoft | Maybe we should solve that with a simple stupid solution and just force all the references to be built in the addPath function? | 22:06:57 |
| 11 Oct 2021 |
| tomberek | Perhaps, but I’m not sure what semantics or evaluation properties need to be preserved. | 00:52:01 |
| balsoft | In reply to @tomberek:matrix.org
Well. You may be getting lucky that the references exist in your store already. It’s possible that can result in dangling references. Wait, how can referenced paths not exist in the store if these are runtime references, and the path is already in nix store? Doesn't nix do a pretty good job at making sure all the runtime deps are always in the store if the dependent is in the store? | 06:53:11 |
| balsoft | The only problem I can think of is that applying a filter can make some references obsolete | 06:54:11 |
| balsoft | E.g. if you have /nix/store/our-drv/foo -> /nix/store/bar, /nix/store/our-drv/goo -> /nix/store/doo and then you filter out foo, you now have a store path that references bar but never actually links to it in any way | 06:55:19 |
| tomberek | This check was overly restrictive and inaccurate, since it's not about having a context but about having references. We can't copy a path if it has references, since we don't propagate the references to the resulting path.
from PR - eelco. I'm not sure if that's a "we can't propagate" or "we don't (yet) propagate"
| 06:56:37 |
| balsoft | Ahhh, ok, I see | 06:56:52 |
