lib.trivial.pipe "does not have documentation", but it actually does #1110

New issue

Open

opened 2026-01-28 11:20:43 +00:00 by crasm · 2 comments

crasm commented

2026-01-28 11:20:43 +00:00

Describe the bug

The function lib.trivial.pipe clearly has documentation in <nixpkgs>/lib/trivial.nix alongside other functions, yet in nix repl, running :doc lib.trivial.pipe returns an error.

Steps To Reproduce

$ nix repl
> :l <nixpkgs>
> :doc lib.trivial.pipe

Expected behavior

The documentation should appear in the repl, like the other functions in trivial.nix do.

`nix --version` output

nix (Lix, like Nix) 2.93.3
System type: x86_64-linux
Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux, x86_64-v4-linux
Features: gc, signed-caches
System configuration file: /etc/nix/nix.conf
User configuration files: /home/core/.config/nix/nix.conf:/etc/xdg/nix/nix.conf:/home/core/.nix-profile/etc/xdg/nix/nix.conf:/nix/profile/etc/xdg/nix/nix.conf:/home/core/.local/state/nix/profile/etc/xdg/nix/nix.conf:/etc/profiles/per-user/core/etc/xdg/nix/nix.conf:/nix/var/nix/profiles/default/etc/xdg/nix/nix.conf:/run/current-system/sw/etc/xdg/nix/nix.conf
Store directory: /nix/store
State directory: /nix/var/nix
Data directory: /nix/store/hz1f5nibclwljprc90zjb8rk42hjmh2z-lix-2.93.3/share

Additional context

Latest cppnix shows the documentation in repl, including the source code location. However, it fails to find the source code when using :e lib.trivial.pipe, which is curious. (Editing works for other functions in trivial.nix just fine.)

Noogle claims that lib.trivial.pipe is a builtin, indicating it is a primop in their evaluation. This is even more curious, since AFAICT the definition of pipe is quite clear in trivial.nix.

I think what is happening is that lib.trivial.pipe is somehow evaluated to be a primop (isPrimOp() -> true), so the v.isLambda() branch doesn't get taken.

Neither cppnix nor lix are handling this correctly. I suspect it's related to the pipe-operator somehow, though enabling or disabling the feature makes no difference. Also, as a casual observer, nothing in the merge commits for both lix and cppnix pipe-operator PRs look like they can cause this issue.

## Describe the bug The function `lib.trivial.pipe` clearly has documentation in [`<nixpkgs>/lib/trivial.nix`](https://github.com/NixOS/nixpkgs/blob/bfc1b8a4574108ceef22f02bafcf6611380c100d/lib/trivial.nix#L150) alongside other functions, yet in `nix repl`, running `:doc lib.trivial.pipe` returns an error. ## Steps To Reproduce 1. `$ nix repl` 2. `> :l <nixpkgs>` 3. `> :doc lib.trivial.pipe` ## Expected behavior The documentation should appear in the repl, like the other functions in `trivial.nix` do. ## `nix --version` output ``` nix (Lix, like Nix) 2.93.3 System type: x86_64-linux Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux, x86_64-v4-linux Features: gc, signed-caches System configuration file: /etc/nix/nix.conf User configuration files: /home/core/.config/nix/nix.conf:/etc/xdg/nix/nix.conf:/home/core/.nix-profile/etc/xdg/nix/nix.conf:/nix/profile/etc/xdg/nix/nix.conf:/home/core/.local/state/nix/profile/etc/xdg/nix/nix.conf:/etc/profiles/per-user/core/etc/xdg/nix/nix.conf:/nix/var/nix/profiles/default/etc/xdg/nix/nix.conf:/run/current-system/sw/etc/xdg/nix/nix.conf Store directory: /nix/store State directory: /nix/var/nix Data directory: /nix/store/hz1f5nibclwljprc90zjb8rk42hjmh2z-lix-2.93.3/share ``` ## Additional context Latest cppnix shows the documentation in repl, including the source code location. However, it fails to find the source code when using `:e lib.trivial.pipe`, which is curious. (Editing works for other functions in `trivial.nix` just fine.) [Noogle claims that `lib.trivial.pipe` is a builtin, indicating it is a primop in their evaluation.](https://noogle.dev/f/lib/trivial/pipe) This is even more curious, since AFAICT the definition of pipe is quite clear in trivial.nix. I think what is happening is that `lib.trivial.pipe` is somehow evaluated to be a primop (`isPrimOp() -> true`), so the [`v.isLambda()`](https://git.lix.systems/lix-project/lix/src/commit/57373cba6fbf9057711db709d91ca40dee0c1f5a/lix/libcmd/repl.cc#L1065) branch doesn't get taken. Neither cppnix nor lix are handling this correctly. I suspect it's related to the pipe-operator somehow, though enabling or disabling the feature makes no difference. Also, as a casual observer, nothing in the merge commits for both lix and cppnix pipe-operator PRs look like they can cause this issue.

crasm added the

bug

label

2026-01-28 11:20:43 +00:00

crasm commented

2026-01-28 11:22:30 +00:00

Author

I'm going to keep investigating this because I find it interesting and I need the excuse to look into nix internals and get a lix development env set up. Any pointers appreciated however

pennae commented

2026-01-28 11:45:48 +00:00

Owner

pipe is a builtin, just a partially applied one. you're right about the branch not taken as a result, but at least in this case we have an attrpath we can still extract a position from to pass to the documentation extractor. should be pretty straight-forward if you want to try :)

`pipe` *is* a builtin, just a partially applied one. you're right about the branch not taken as a result, but at least in this case we have an attrpath we can still extract a position from to pass to the documentation extractor. should be pretty straight-forward if you want to try :)

👍 1