Sender | Message | Time |
---|---|---|
11 Jul 2021 | ||
true, that would be nice to have | 12:23:27 | |
15:46:00 | ||
I dunno if I like that. I like how the current setup can share configuration between home-manager and nixos, even if using hm standalone. Why would we give that up? | 17:35:07 | |
I don't see us giving that up: a In fact and as far as I can tell right now, the only requirement for a hm config to work portably is to set | 21:03:10 | |
* I don't see us giving that up: a `hm` config can still be created independently of any specific host, and the same config then can still be deployed to any nixos host. In fact and as far as I can tell right now, the only requirement for a hm config to work portably on a non-nixos host is to set `useUserPackages = false` while setting it to true on a nixos host seems to be a good idea. | 21:03:49 | |
* I don't see us giving that up: a `hm` config can still be created independently of any specific host, and the same config then can still be deployed to any nixos host. In fact and as far as I can tell right now, the only requirement for a hm config to work portably on a non-nixos host is to set `useUserPackages = false` while on the other hand setting it to true on a nixos host seems to be a good idea. | 21:04:10 | |
* I don't see us giving that up: a `hm` config can still be created independently of any specific host, and the same config then can still be deployed to any nixos host. In fact, and as far as I can tell right now, the only requirement for a hm config to work portably on a non-nixos host is to set `useUserPackages = false` while on the other hand setting it to true on a nixos host seems to be a good idea. | 21:04:32 | |
I also think ot might be prohibitive for a "portable" user to depend on nixos host config values of any particular host. However, currently this seems to be our thought model which the PRs propose to rectify. | 21:05:50 | |
* I also think it is prohibitive for a "portable" user to depend on nixos host `config` values of any particular host. However, currently this seems to be our thought model which the PRs propose to rectify. | 21:06:06 | |
* I also think it is prohibitive for a "portable" user to depend on nixos host `config` values of any particular host. However, currently this seems to be our thought model which the PRs seeks to rectify. | 21:06:41 | |
In fact, I think our current implementation simply ignores the difference between a host-specific application of a hm config and a "portable" variant of the same config and treats them as the same which might result in intricate problems in either use case. | 21:08:04 | |
* In fact, I think our current implementation simply ignores the difference between a host-specific application of a `hm` config and a "portable" variant of the same config and treats them as the same which might result in intricate problems in either use case. Such problems manifest when a `useUserPackes = false` - nixos hm module suddenly is used in conjunction with a `userUserPackages = true` config. However, this is currently the case if you would use the `home-manager` cli in good faith with the current inplementation | 21:10:45 | |
* In fact, I think our current implementation simply ignores the difference between a host-specific application of a `hm` config and a "portable" variant of the same config and treats them as the same which might result in intricate problems in either use case. Such problems manifest when a `useUserPackes = false` - nixos hm module suddenly is used in conjunction with a `userUserPackages = true` config. However, this is currently the case if you would use the `home-manager` cli in good faith with the current implementation. | 21:10:57 | |
* In fact, I think our current implementation simply ignores the difference between a host-specific application of a `hm` config and a "portable" variant of the same config and treats them as the same which might result in intricate problems in either use case. Such problems could manifest when a `useUserPackes = false` - nixos hm module suddenly is used in conjunction with a `userUserPackages = true` config. However, this is currently the case if you would use the `home-manager` cli in good faith with the current implementation. | 21:11:24 | |
Hence I think it is better to provide a fully nixos-compliant hm config as user@host so that good faith use of home-manager cli at least does not do any potential harm. And render a separate user with useUserPackages = mkForce false so that this config is guaranteed to work on non-nixos hosts. | 21:13:10 | |
* Hence I think it is better to provide a fully nixos-compliant `hm` config as `user@host` so that good faith use of `home-manager` cli at least does _not_ do any potential harm. And render a separate `user` with `useUserPackages = mkForce false` so that this config is guaranteed to work on non-nixos hosts. | 21:13:34 | |
* Hence I think it is better to provide a fully nixos-compliant `hm` config as `user@host` so that good faith use of `home-manager` cli at least does _not_ do any potential harm. And render a separate `user` with `useUserPackages = mkForce false` so that such config is guaranteed to work "portably" on non-nixos hosts. | 21:14:02 | |
Lastly, one might want to deploy a user (normally used on 86_64-linux) on an aarch64 server. user@host would not help, since that would have 86_64-linux. To successfully "portably" use that user on an aarch64 machine, I'd have to either create a dummy aarch64 host or render a user-acrch64 output for homeConfigurations . | 21:17:24 | |
* Lastly, one might want to deploy a `user` (normally used on 86_64-linux) on an aarch64 server. `user@host` would not help, since that would have 86_64-linux. To successfully "portably" use that user on an aarch64 machine, I'd have to either create a dummy aarch64 host or render a `user-aarch64` output for `homeConfigurations`. | 21:17:33 | |
12 Jul 2021 | ||
17:37:26 | ||
17:37:35 | ||
Hello! | 17:38:19 | |
Excuse me for going a little bit "off-topic", but I think some of you here may find this interesting - for the past several months I've been working on a framework very heavily inspired by DevOS (and retaining a very similar folder/configuration structure), oriented more towards enterprise/high-complexity configurations. I'd be interested to know what you all think - I believe there are definitely some lessons that could be learnt on either side as far as best practices go :) https://github.com/ArctarusLimited/KuiserOS | 18:52:54 | |
It shares a bunch of library functions, and more or less functions in a very similar way, but it's quite different "under the hood" | 18:53:59 | |
It's quite a niche thing, and it is not intended to be any sort of replacement for devos, but I think it's an interesting proof of concept, and so far the composable/DRY model works pretty well for child flakes | 19:00:51 | |
Hello everybody, I'm trying to use overrides https://devos.divnix.com/concepts/overrides.html to get neovim v0.5.0 with this home-manager option, but probably I'm missing something, because it's still pulling the version from the nixos channel instead of latest | 19:27:59 | |
I've added neovim-unwrapped to the list of pkgs in overlays/overrides.nix | 19:28:49 | |
is home-manager ignoring the overlay / override? https://github.com/nix-community/home-manager/blob/master/modules/programs/neovim.nix#L135 | 19:29:30 | |
thank you for this awesome piece of open-source software ( : really enjoying it as a base for declarative configuration management | 19:30:32 | |
Try setting config.home-manager.useGlobalPkgs = true; | 19:44:08 |