Nix Hackers | 893 Members | |
| For people hacking on the Nix package manager itself | 188 Servers |
| Sender | Message | Time |
|---|---|---|
| 12 Mar 2025 | ||
| didn't you say that you wanted to do it without using --store? | 03:44:11 | |
| i meant subsequent commands | 04:09:50 | |
| don't need the --store after that | 04:09:56 | |
| @roberthensing:matrix.org: FYI I noticed Linus Heckmann did some interesting recent commits to lix for GC fixes | 22:56:05 | |
| 13 Mar 2025 | ||
In reply to @fzakaria:one.ems.hostNIX_CONFIG | 01:01:34 | |
| 07:46:39 | ||
| Fixing very significant debugger performance regression introduced in 2.21: https://github.com/NixOS/nix/pull/12645 | 13:42:40 | |
What do we think of suffixing fields with _ to make them visually distinct from locals/params? I'm open to it (implicit this-> may have been a mistake, hurting understanding and refactoring) but esp John Ericson tomberek Eelco Mic92 will also have to look at such code | 14:59:57 | |
| Robert Hensing (roberth): my lsp does it locally for my editor, but we don't have in github, so might be worth it. There is clang-tidy also can do this automatically: https://clang.llvm.org/extra/clang-tidy/checks/readability/identifier-naming.html#cmdoption-arg-ClassMemberPrefix | 15:05:03 | |
| * Robert Hensing (roberth): my lsp does it locally for my editor with colors, but we don't have in github, so might be worth it. There is clang-tidy also can do this automatically: https://clang.llvm.org/extra/clang-tidy/checks/readability/identifier-naming.html#cmdoption-arg-ClassMemberPrefix | 15:06:44 | |
| Also suffix, nice! @Mic92 on GitHub we don't have that highlighting, for doing reviews | 15:19:39 | |
| I wouldn't love it, seems a bit ugly. Yeah seems better if the lsp can figure it out. | 15:30:18 | |
In reply to @roberthensing:matrix.orgWe do use a _ suffix for other things right now FYI | 15:40:41 | |
yeah, mostly for Sync state values | 16:00:58 | |
| I'm trying to re-implement the way content-addressed derivations do dependency resolution from unresolved to resolved (aka basic) derivation, but outside of Nix - because I'm trying to do stricter validation with different signatures. I've gotten fairly far with that, but I'm seeing some "placeholder paths" like So I'm wondering, how do those placeholder paths work? I saw that (I also see one such path in resolved derivations, but there it's always the same | 16:06:18 | |
In reply to @mschwaig:matrix.orgthey are values derived from either the current drv's output, or any input drv + its output. its representation is / then the nixbase32 repr of the full sha256 of either "nix-output: " or "nix-upstream-output: :<the name the output would have; so either drv's name or append a dash and the output name>" | 16:39:23 | |
| you'll have to pessimistically calculate every possible placeholder and its replacement value, then just search+replace the environment and builder args for said placeholders | 16:40:00 | |
| (note though, you may want to check the signature that gets signed for realisations if you haven't already; it might serve your needs if you just want a drv + its realised input paths signed) | 16:41:04 | |
In reply to @puck:puck.moeuh, one colon. element's not letting me edit this message :v | 16:42:22 | |
NIX_REMOTE | 20:41:29 | |
| its really badly documented but it is actually equivalent to --store internally; see my hastily scrawled notes on all env-vars used by cppnix derivatives https://docs.lix.systems/manual/lix/stable/contributing/testing.html?highlight=NIX_REMOTE#used-by-lix | 20:42:58 | |
| You can also use just use NIX_CONFIG, the one env var to rule them all | 20:48:09 | |
| mhm | 20:49:55 | |
| it seems like sometimes env-vars get introduced like NIX_ABORT_ON_WARN which should just be more NIX_CONFIG | 20:51:35 | |
| If they correspond to an option, yes | 20:55:44 | |
| Btw, you should see what we just did to derivation goal | 20:55:58 | |
| Even if you're gonna rewrite it in Rust anyways | 20:56:06 | |
| 14 Mar 2025 | ||
yeah, NIX_ABORT_ON_WARN does, i am not sure why it was added; we caught this in code review of builtins.warn | 00:04:27 | |
| No idea either | 04:20:24 | |
Continuity with Nixpkgs lib.warn, and in turn the ability to produce a trace from the first warning encountered | 08:20:46 | |