| 22 Sep 2021 |
 ilkecan | tomberek: I tested your branch and it doesn't look like it changes how strings with contexts are handled inside builtins.path or builtins.filterSource. I also wrote this. If needed I can create minimal working examples later but I need to log out now. | 00:40:22 |
 colemickens 🏳️🌈 | what's the most ergonomic way to have a nix run that maps to a script? | 06:52:03 |
| colemickens 🏳️🌈 | should I just point it at bash, and then, supply it args? idk | 06:52:18 |
 edrex | i'm trying to install nixGL with nixUnstable. There's a big issue thread discussing what to do about flakes there. Am I missing something in thinking a short term solution is just introducing an impure flake and instructing users to pass --impure to nix profile install? https://github.com/guibou/nixGL/issues/16#issuecomment-925300321 | 20:23:19 |
| edrex | also, as a user on nixUnstable am I on a strictly no-Channels diet? this is my understanding and I haven't had any thought for them till this moment. | 20:25:23 |
 tomberek | Flakes steer you toward not using channels in the way they were used in legacy Nix. Do you use <nixpkgs> or NIX_PATH? The issues those things bring up are one of the main motivations behind flakes. | 20:30:36 |
| edrex | <nixpkgs> as in a global input for expressions? So far my only expressions are under a NixOS system flake, and I'm just using nix as a stateful package manager on other hosts, with nix profile ... So I guess no? I see that NIX_PATH is a way to override the behavior of the nix tool. I'm not doing that AFAIK. | 20:36:20 |
| edrex | as a new user trying to do things purely with flakes, i'm in an awkward position with the documentation | 20:38:18 |
| edrex | on one hand, legacy docs like nix pills are foundational | 20:38:35 |
| edrex | on the other, they are, in practical terms, largely irrelevant with nixFlakes | 20:39:37 |
| edrex | so I have skimmed them but I miss a lot of foundation that way/ | 20:40:01 |
 balsoft | In reply to @edrex:matrix.org
i'm trying to install nixGL with nixUnstable. There's a big issue thread discussing what to do about flakes there. Am I missing something in thinking a short term solution is just introducing an impure flake and instructing users to pass --impure to nix profile install? https://github.com/guibou/nixGL/issues/16#issuecomment-925300321 Could you tl;dr on what the problem is? | 20:40:07 |
| tomberek | Understood, flakes are not completely done, nor have they moved out of experimental status. So you are in a bit of an awkward moment. I would like to re-do "nix pills" with flakes and nix2.4 cli at some point. | 20:40:21 |
| tomberek | yes, short term solution is "--impure" | 20:40:49 |
| edrex | @balsoft you mean for the nixGL project, or for me trying to consume it as it is? (assuming the former) | 20:41:03 |
| balsoft | In reply to @edrex:matrix.org
on the other, they are, in practical terms, largely irrelevant with nixFlakes Most of nix pills are still very relevant with flakes | 20:41:29 |
| edrex | i gather it does some install-time introspection on your system to figure out what graphics drivers you are using | 20:41:47 |
| balsoft | In reply to @edrex:matrix.org
i gather it does some install-time introspection on your system to figure out what graphics drivers you are using Oh, that sounds impure by design then | 20:42:02 |
| edrex | i'm honestly not sure tho | 20:42:18 |
| edrex | i will try to make an impure flake for it and install that way | 20:42:50 |
| balsoft | I guess it would be nicer if it was possible to specify what hardware you need declaratively | 20:43:36 |
| balsoft | And perhaps add an auto-detector thing that would work similar to hardware-configuration.nix | 20:43:53 |
| balsoft | * And perhaps add an auto-detector thing that would work similar to nixos-generate-config --show-hardware-configuration | 20:44:18 |
| edrex | In reply to @tomberek:matrix.org
Understood, flakes are not completely done, nor have they moved out of experimental status. So you are in a bit of an awkward moment. I would like to re-do "nix pills" with flakes and nix2.4 cli at some point. yeah, i think that's what's needed. and yeah, i knew what awkwardness I was diving into. My intention is/was to provide some early product testing, which means I need to complain in useful ways/volumes | 20:45:08 |
| edrex | In reply to @balsoft:balsoft.ru
And perhaps add an auto-detector thing that would work similar to nixos-generate-config --show-hardware-configuration so it would do some runtime detection and use that to configure? somehow it seems like they also want to have all the possible binary graphics drivers as inputs. maybe they're not using the system drivers but matched copies? I'm not sure. | 20:46:59 |
| edrex | err, "... and use that to produce a description of the local driver configuration which would be (pure) input to subsequent evaluation runs?" | 20:48:14 |
| 23 Sep 2021 |
|  zrsk joined the room. | 23:37:35 |
| zrsk | Hi!
Someone here knows a way to run nix flake check excluding some outputs? I would like to specify the excluded outputs directly in the cli.
The reason is that I want to be able to run that command on my machine which supports cross compilation but I want to exclude that outputs that need it when I run the command in a github workflow (where cross compilation is not supported and where I can't have an aarch64 host). | 23:41:41 |
| 24 Sep 2021 |
 niksnut | In reply to @aciceri:nixos.dev
Hi!
Someone here knows a way to run nix flake check excluding some outputs? I would like to specify the excluded outputs directly in the cli.
The reason is that I want to be able to run that command on my machine which supports cross compilation but I want to exclude that outputs that need it when I run the command in a github workflow (where cross compilation is not supported and where I can't have an aarch64 host). Currently there isn't. I guess we could add an --exclude flag or something like that... | 09:45:48 |
| balsoft | In reply to @niksnut:matrix.org
Currently there isn't. I guess we could add an --exclude flag or something like that... Could we just add --only-eval-current-platform ? I think it would solve the most common issue (which is IFD in checkable outputs) | 09:46:48 |
