 | Nix Hackers | 901 Members |
| For people hacking on the Nix package manager itself | 191 Servers |
| Nix Hackers | 901 Members |
| For people hacking on the Nix package manager itself | 191 Servers |
| Sender | Message | Time |
|---|---|---|
| 18 Apr 2025 | ||
 Winter | anyone know if the docs to build locally w/ Meson are still accurate? the prefix env stuff doesn’t seem to work properly — --prefix gets properly passed to meson setup but ninja’s install phase is still trying to install into $PREFIX | 08:58:53 |
 allrealmsoflife | In reply to @winter:catgirl.cloudAre you trying to build Nix from source? Which docs are you following, the official ones building from source dont say much, and last time I failed building Nix from source too. | 09:10:44 |
 trofi | New json-3.12.0 exposed a bug in how nix deserializes integers: https://github.com/NixOS/nix/issues/13046 | 15:54:09 |
 John Ericson | thanks trofi | 16:59:23 |
| John Ericson | I didn't know we had a $PREFIX defined? | 16:59:54 |
| Winter | In reply to @Ericson2314:matrix.orgin the default nix-shell $PREFIX points to nix-util’s $out ;) | 17:00:16 |
| John Ericson | Winter: oh hmm that might be an artifact of how we made the dev shell? | 17:01:27 |
| Winter | yeah. but i guess that begs the question: has nobody tested the dev shell/does nobody use it? | 17:02:23 |
| Winter | like should a shell hook be added to just unset $prefix/$out? that seems simplest but shrug | 17:02:53 |
| Winter | or dontSetPrefix=true ig | 17:03:09 |
| John Ericson | Winter: I don't think we do much installing from the dev shell | 19:21:05 |
| Winter | fair, guess you just use the bins | 19:21:24 |
| John Ericson | what made you want to do that? | 19:21:24 |
| John Ericson | (though I do recall runnning installPhase and it worked with nix develop) | 19:21:40 |
| John Ericson | trofi: gotta say the nlohmann people don't seem super clear about this | 19:22:19 |
| Winter | nothing in particular | 19:22:33 |
| Winter | was just linearly following the docs | 19:22:33 |
| John Ericson | e.g. is a positive integer always parsed as an unsigned number? | 19:22:39 |
| John Ericson | do you need to try both just to be sure? | 19:22:44 |
| John Ericson | maybe the docs need to be changed? | 19:23:07 |
| John Ericson | before you had to install for the install tests | 19:23:12 |
| John Ericson | with since Meson you don't need t | 19:23:18 |
| John Ericson | * with since Meson you don't need to | 19:23:19 |
| Winter | In reply to @Ericson2314:matrix.orgmight be best to remove the install section, yeah | 19:32:59 |
| trofi | Yeah. AFAIU the https://github.com/nlohmann/json/issues/4475 as get_ref() can expose mutable references it's unsafe to return signed reference to unsigned underlying type (breaks -fstrict-aliasing assumptions). It was allowed by accident. And AFAIU whether to use signed or unsigned internally is dependent on actual json data. 0 is unsigned while -1 is signed. | 19:46:48 |
| 19 Apr 2025 | ||
 Ochoa left the room. | 21:30:18 | |
 jaen | I'm not sure if it's the best place to ask this, but I figured subflakes are new enough and not yet ironed out that it might as well be. I tried to play around with them with the latest nix to see how the situation has improved and I have two questions: a) should I expect subflakes to work without a git repo, or not? If lockfiles are already there it seems to keep working even if I drop the .git folder, but without it will fail to generate the lock file complaining about access to absolute path '/nix/store/flake.nix' is forbidden in pure evaluation mode for a subflake that refers to its parent,b) in another test I have a root flake, and two child flakes which are siblings. Both siblings refer to the parent, and one of the siblings refer to another, which results in a found circular import of flake for the root flake. Is this something that is not supposed work "by specification" or is it a consequence of https://github.com/NixOS/nix/issues/7730 not being resolved yet? I feel intuitively that this should work, but maybe there's something I missing that makes it impossible? | 22:07:11 |
 alexfmpe changed their profile picture. | 23:56:01 | |
| 20 Apr 2025 | ||
 orhosko joined the room. | 08:51:54 | |
 Robert Hensing (roberth) | a: Relative path flakes are an incremental improvement. They create a new relation, between a flake and a "parent" whose source it is relative to. The source of a path flake (ie non-git) is currently always the directory of the flake in isolation, so inputs can only refer to subdirectories.This could be improved by parsing the flake.nix in the context of the whole file system first, figure out the locations of the closure of path inputs, and use those. I don't think we can treat them similarly to git flakes though, because that would mean taking the most specific common ancestor directory as the only "parent source" for all path inputs, which will include things like ~/src or /. That's not feasible with the current flake to store path copying solution, but even after we fix that, it would not be checking any kind of hermeticity. I think the property we want is that the knowing the inputs closure is sufficient to know which files are available to evaluation, and such a single source wouldn't provide much info.Instead, we could import these flakes individually and by default disallow any "implicit", non- inputs parent references like "${readFile ../version.txt}". These could be re-allowed with an explicit parent = ../.; field in the flake.nix top level attrset. This is more explicit/hermetic and makes the eval cache more effective by ignoring changes in unrelated sibling directories.We could prototype this approach by implementing it for path inputs first and harmonizing the other flake input types with it afterwards. | 11:54:20 |