Sender | Message | Time |
---|---|---|
10 Aug 2024 | ||
Matt Sturgeon | I've opened a draft PR that does it as an https://github.com/NixOS/nixpkgs/pull/333799 | 23:30:29 |
13 Aug 2024 | ||
Austin Horstman joined the room. | 22:45:20 | |
14 Aug 2024 | ||
Robert Hensing (roberth) | Matt Sturgeon: would you (or anyone I guess?) be interested in completing types.record from https://github.com/NixOS/nixpkgs/pull/257511? I don't have much time for this kind of thing due to other responsibilities recently | 14:41:16 |
Matt Sturgeon | I also don't know how much time I can dedicate to it. I had looked at it before when exploring solutions to https://matrix.to/#/!wfudwzqQUiJYJnqfSY:nixos.org/$mVuETvj4dPJNF6ZUdVEVvWmp07L5G3X-6y0bk-NmCP4?via=nixos.org&via=matrix.org&via=nixos.dev, however I came to the conclusion it is an interesting (and useful looking) type, but not a viable solution to the problem we have in nixvim. I'll attempt to clarify a little in my response to your (very helpful) feedback in #333799. | 14:45:44 |
Robert Hensing (roberth) | ohh saw the OP but glossed over the matrix thread - well good to have the context in github as well I guess | 14:50:44 |
Matt Sturgeon | Don't blame you, it ended up being a long thread (as usual!) | 14:51:11 |
Matt Sturgeon | Thanks again Robert Hensing (roberth) for your feedback and for reminding me of your existing proposals! I've posted my initial thoughts on github. And further; Reading through your simple/minimal module eval proposal, I think that's a great solution provided defining config from outside the simple-module type looks the same as defining config for a submodule type; i.e. many of the features you mention arent supported ( Enforcing one module/option per attr level (i.e. no nested options) sounds like a reasonable simplification too. My main concern is that "perfection" here may be acting as the enemy of "good"; i.e. your proposal is great, but will be much more effort to actually get merged into nixpkgs. From a different perspective, there's also some simplicity in not reinventing the wheel here, just to support one small feature ( | 15:19:50 |
Matt Sturgeon | Hm, I'm not sure why I was under the impression that the If we can define nested | 15:29:31 |
Matt Sturgeon | * Hm, I'm not sure why I was under the impression that the If we can define nested | 15:30:22 |
Robert Hensing (roberth) | Yeah records can have any type in their fields, including other records. It's simpler, lazier and more efficient that way. | 16:28:23 |
nbp | I have no time this week, I might give it a look next week if needed. | 16:39:28 |
Matt Sturgeon | I'll play around with adding optionalFields to types.record , won't have anything "finished" today though. I believe after that it's just adding docs and getting reviews? | 16:42:06 |
Matt Sturgeon | I have a draft PR up based on Robert Hensing (roberth)'s prior work, seems to be working but haven't polished it up or thoroughly tested it yet. | 17:58:12 |
15 Aug 2024 | ||
mr-qubo | I'm using modules in my nixos config. For every user in my config I write something like this:
Is it possible to somehow extend | 21:51:03 |
Matt Sturgeon | If you just want to include hm-common for all users, have you considered home-manager's sharedModules option? | 22:15:46 |
nbp | mr-qubo: yes, by extending the option declaration.
| 22:26:32 |
nbp | * mr-qubo: yes, by extending the option declaration.
| 22:29:01 |
16 Aug 2024 | ||
SebTM | Hey, I'm trying to access pkgs.system in a nixosModule for "imports" to determinate if I want to load a certain module based on x86 or aarch64 - but it goes to infinite recursion encountered while when using it in e.g. options it works? (tested with builtins.trace) | 07:44:07 |
Matt Sturgeon |
One approach would be to always load the module, but only enable its options on certain systems. | 12:24:53 |
Matt Sturgeon | Another approach would be to check
(Same applies to wrappers, such as | 14:26:54 |
17 Aug 2024 | ||
Matt Sturgeon | * Another approach would be to check
(Same applies to wrappers, such as | 22:17:28 |
Matt Sturgeon | * SebTM One approach would be to always load the module, but only enable its options on certain systems. | 22:17:41 |
Matt Sturgeon | * Another approach would be to check
(Same applies to wrappers, such as | 22:18:02 |
Matt Sturgeon | Anyone know why overriding an option-type's E.g. I have a submodule with a deprecated sub-option. Since the submodule's final value is often fully evaluated (e.g. printed to lua using I figured I could do something like:
However this doesn't seem to have any effect, For this specific example, I could use an option's I had a the same issue a few weeks ago when extending Seeing as | 22:31:16 |
Matt Sturgeon | * Anyone know why overriding an option-type's E.g. I have a submodule with a deprecated sub-option. Since the submodule's final value is often fully evaluated (e.g. printed to lua using I figured I could do something like:
However this doesn't seem to have any effect, For this specific example, I could use an option's I had a the same issue a few weeks ago when extending Seeing as | 22:32:23 |
Matt Sturgeon | * Anyone know why overriding an option-type's E.g. I have a submodule with a deprecated sub-option. Since the submodule's final value is often fully evaluated (e.g. printed to lua using I figured I could do something like:
However this doesn't seem to have any effect, For this specific example, I could use an option's I had a the same issue a few weeks ago when extending Seeing as | 22:33:54 |
18 Aug 2024 | ||
SebTM | In reply to @mattsturg:matrix.orgAwesome thanks for explaining ✌🏻👌🏻🙏 | 07:38:58 |
r3vx joined the room. | 14:18:31 | |
22 Aug 2024 | ||
Artur Manuel joined the room. | 13:04:02 | |
Artur Manuel changed their profile picture. | 14:52:58 |