<cfinch>
One other thing i'm confused about -- can I just drop a module in to the home-manager/modules/programs folder for example , and be able to refer to it in my home.nix ?
<ldlework>
cfinch: I think you should probably read the entire nixlang docs before moving on
<ldlework>
Trying to get anything done when you don't quite understand the language is gonna be really hard.
<rycee>
cfinch: Using imports should work. That's exactly what I do. What kind of error message are you getting?
<rycee>
cfinch: If you have a custom module you'd like to use then you can import it using the same imports attribute.
<cfinch>
With a custom module , am I able to put the file in the modules folder and then refer to it without having to use the imports attribute ?
cole-h has quit [Quit: Goodbye]
<cfinch>
so just say programs.emacs.enable = true; without an imports []; statement ..
<cfinch>
i put a java.nix file in the modules folder but get attribute doesn't exist type error
cole-h has joined #home-manager
<cfinch>
i don't quite understand how that works
<rycee>
Well, the programs.emacs.enable option should always be available in a HM configuration since it's included in the default modules. But in general you must inform the module system about custom modules. It would probably be possible to include a directory using `builtins.readDir` in a suitable way but it's available out of the box.
<cfinch>
ok so if i want to use the custom emacs.nix , then I do an imports [emacs.nix;] but don't include the programs.emacs.enable option (as that would pick up the default module)
<rycee>
cfinch: Ah, now I'm confused. You define a new `programs.emacs.enable` option in your `emacs.nix` file?
<cfinch>
no i don't define that , but programs.emacs.init = { enable = true; is included (it is your config file :-) )
<rycee>
Right, but that is `programs.emacs.init.enable`, not `programs.emacs.enable`…
<cfinch>
sure , but after doing my home-manager switch , and no errors , then typing emacs on command line returns 'no emacs command found' error
<cfinch>
command not found: emacs
<rycee>
Do you have `programs.emacs.enable = true` in your configuration? Could you share your `home.nix`?
<cfinch>
i don't have that in home.nix ,
<cfinch>
SEND rycee []
<cfinch>
i would send it but i'm afraid this is new to me
<rycee>
cfinch: If you have a github account then you can PM me a link with a gist link.
<dermetfan>
rycee: It seems the workload with PRs and issues grew quite a bit. Sometimes I would like to help but I'm not sure whether some code meets your expectations. Is there anything (other than contributing.adoc) I can do to not merge unsatisfactory PRs?
<rycee>
dermetfan: I responded to the PM a little while ago but my answer was "No, contributing.adoc is the only thing that exists. I've been trying to improve it lately with more concrete guidelines."
<rycee>
I think just doing a bit of reviewing or even just highlighting PRs where the submitter has made commits after the first round of comments would be very helpful.
<rycee>
Also triaging issues, I hardly look at them any more and only act on the ones that seem really breaking.
<rycee>
cfinch: Yeah, unless `my-emacs.nix` includes `programs.emacs.enable = true` then you wouldn't actually get an Emacs install. Try adding `programs.emacs.enable = true` to your `home.nix`.
<dermetfan>
rycee: Sorry, seems I still need to learn this irc client. For merging, I'll just go with my gut feeling then. Highlighting PRs using the GitHub approve/review feature I guess, and triaging with labels and comments?
<cfinch>
ok, but that will pick up the default module emacs , and ignore the config defined in the emacs.nix file ? or the emacs.nix file just adds some config ?
<rycee>
cfinch: Yeah, the `program.emacs.init` thing is just a way to build an Emacs `init.el` and automatically set the `programs.emacs.extraPackages` option. So it works together with `progams.emacs.enable`, not replacing it.
<rycee>
cfinch: Basically, I import the `emacs.nix` file into all my HM configurations but I only actually make use of it in some by adding `programs.emacs.enable = true`.
asymptotically has quit [Remote host closed the connection]
<rycee>
dermetfan: Yeah, that sounds reasonable if you take the guidelines into account before the gut feeling part :-)
<cfinch>
Thanks rycee ! think I have it now
<cfinch>
When including packages in our home.nix , e.g. home.packages = [ pkgs.atom ]; , pkgs don't give you any options to configure the pkgs, correct ? then why not just use modules instead ?
<cfinch>
yes that's probably a basic question in which i need to learn more about nixpkgs ,
<cfinch>
but the home.nix file is a mixture between pkgs and then modules , whereby pkgs are just modules without any attributes..
<rycee>
Hmm, you mean configuring atom or pkgs (Nixpkgs) itself?
<cfinch>
atom just an example,, I mean when we are making up our home.nix file , it seems to be a mixture between modules and pkgs,
<ldlework>
cfinch: sorry for my useless advice
<rycee>
Well, `home.packages` is just another option inside the 'home-environment" module. The packages you list there are just installed to your profile.
{^_^} has joined #home-manager
<rycee>
Some software have been given special modules that also generate configuration or service files for that software. As a convenience these special modules usually also add the software package to `home.package`.
<cfinch>
but why not have everything in the format of programs.atom = {} (for example) , as it gives scope for further configuring
<__monty__>
Because it takes manual effort.
<cfinch>
special modules is same as if i do a 'custom module' ?
<rycee>
Well, in principle I guess it would be possible to dynamically create a `programs.<pname>.enable` option for all attributes in `all-packages.nix` but I think it would be pretty confusing to use and tricky to get right.
<cfinch>
sure ok, i bow to you guys' insight
<rycee>
The `emacs-init.nix` does something like that. If you do `programs.emacs.init.usePackage.vterm.enable`, for example, the module will look through the emacs packages attribute set and see if there is a package whose attribute name matches "vterm" if there is then that package will be added to `programs.emacs.extraPackages`.
<DamienCassou>
why is `systemd.user.startServices` not `true` by default?
<rycee>
Damien Cassou: Because it adds a Ruby dependency :-(
<rycee>
Some time ago I started work on a small and better (directly using systemd's dbus interface) program that compiles to a static binary. If I get that working then I'll switch that option to default to `true` since it would just add a few hundred KiB to the closure.
<DamienCassou>
this makes sense. Thank you
<DamienCassou>
Should programs defined in home-manager try to specify all options of the packages (to get nix types and documentation) or should they instead declare a generic "settings" attribute set that is written as is to package's configuration files?
<rycee>
In general it's best to avoid too many options.
<rycee>
I did check the powerline-go module a little while ago and that would be a candidate for slimming down the number of options but I haven't had time to really look at how powerline-go's command line params are set up. It might be possible to represent them in a nicer way in Nix compared to the very limited format allowed by command line arguments.
<energizer>
rycee: why avoid too many options?
<rycee>
energizer: See the link above.
<energizer>
i see
<DamienCassou>
rycee: I will work on my PR to simplify it. Thank you!
<rycee>
energizer: But mainly it is a maintenance issue. IMHO it is ok to have a largish number of options where you can be certain that the software offers some guarantees about forward/backward compatibility
<rycee>
Like OpenSSH, for example.
<cfinch>
ldlework: np , your advice was correct :-)
<rycee>
But for your bog-standard hobby project less is more :-)
<DamienCassou>
I saw a bunch of programs have non-null default values for many options, e.g., modules/programs/gpg.nix. This means that, if the user doesn't specify any value for these options, they will be written anyway to the configuration file. IMO this is a problem because these default values hide the default values chosen by the upstream author and they make the generated configuration files harder to read. I suggest to
<DamienCassou>
have null as default value in most cases and to only generate lines in configuration files for non-null settings
<cfinch>
Nice observation DamienCassou, I haven't looked much at the configuration files that get generated , with gpg for e.g.
<DamienCassou>
I think the gpg one is a real problem because I don't trust the author of gpg.nix as much as I trust the gnupg authors. I would like that my configuration file has the upstream defaults
<DamienCassou>
(if the author of gpg.nix is one of you, I take that back :-D)
<cfinch>
if I want to use a module in nixpkgs, for example wireshark.nix from nixpkgs/nixos/modules/programs , which isn't available in home-manager, i have to import it as a custom module ? or i'm missing something (again sorry if this is explained on page 1 of manual)
<DamienCassou>
cfinch: from what I understand (which is not much), I think NixOS modules are completely disconnected from home-manager. If you really want to manage a NixOS module through home-manager, you would probably have to create a new module in home-manager. Why is the NixOS module not good enough for you?
<cfinch>
DamienCassou: thanks, that's fine i don't mind it being separate I just wasn't quite sure if that's how it was -- I can create a new module for home-manager .. it is not that the nixos module is not good enough , it is that afai can see there no home-manager module for wireshark
<DamienCassou>
cfinch: why can't you use the module in NixOS?
<rycee>
cfinch: Wireshark wouldn't make much sense in HM since it needs to be installed with a security wrapper, which can only be done at the system level.
<cfinch>
i could use it but doesn't that mean having to include it in /etc/nixos/configuration.nix ? , and would prefer to have it user specific ..
quinn has joined #home-manager
<cfinch>
and that would mean splitting my setup between two systems
<cfinch>
but yeah perhaps can just specify it in configuration.nix
<rycee>
Damien Cassou: About the gpg module I agree that most of those gpg settings should have been omitted by default and included only if an `enableRecommendedSettings` option is set to true.
asymptotically has quit [Quit: Leaving]
<rycee>
Might be worth revisiting for state version 20.09.
<rycee>
cfinch: You must use the NixOS wireshark module. It would be impossible to implement that module in HM.
<rycee>
Because it requires root level access and HM only does things your regular user can do.
<DamienCassou>
rycee: should I open an issue about that gpg settings?
<DamienCassou>
When configuring home-manager through the NixOS module, the `home-manager.users.<user>` should be a function that takes an attribute set with the `pkgs` key. This pkgs overrides the one that was in use. If within this function I import a nix module, this nix module will only be able to access the pkgs passed as argument to `home-manager.users.<user>`. However, there is a package that is in the overriden pkgs that I
<DamienCassou>
would like to be passed to the imported module. How do I do that? The 3 lines I'm talking about are here: http://ix.io/2ocT/nix
<DamienCassou>
in this example, I would like bash.nix to be able to access a package that is only accessible through the overriden pkgs
<dermetfan>
DamienCassou: not sure but maybe you can pass the systemconfig's pkgs to bash.nix using the passthru module `imports = [ <nixpkgs/nixos/modules/misc/passthru.nix> ]`
quinn has joined #home-manager
<rycee>
Damien Cassou: Yeah you can create an issue for gpg. It would be handy to have.
<rycee>
Thanks :-)
<DamienCassou>
dermetfan: thank you. Where would you import that?
<rycee>
Damien Cassou: If you like to replace the HM `pkgs` attribute entirely by the system one then you could try `home-manager.useGlobalPkgs = true;`
<rycee>
That is, the pkgs you get in `home-manager.users.cassou = { pkgs, ... }:` will be the same as the system one.
<dermetfan>
simply in home.nix, although rycee's suggestion seems cleaner
<rycee>
(this disables the HM `nixpkgs.*` options, though)
<cfinch>
rycee: re wireshark, thanks got it..
<DamienCassou>
rycee: you mean this makes it impossible to specify a path for `nixpkgs.config` ?
<rycee>
Damien Cassou: Correct, it entirely replaces the HM `pkgs` argument.
<rycee>
If you want to use the system `pkgs` only for some things then you need another solution. Maybe the passtru one, although I'm not familiar with that one. Or bind the system `pkgs` to a different name and use that name inside the HM configuration.
<DamienCassou>
rycee: I tried the binding solution before but I don't know how to pass a binding to an imported file
<rycee>
Damien Cassou: You could try adding `_module.args.nixosPkgs = nixosPkgs;` to the HM configuration part that is inside the system configuration.
<rycee>
Then you might be able to do `{ pkgs, nixosPkgs, ... }:` in your imported module.
<DamienCassou>
rycee: the `_module.args` solution worked! Thank you
<DamienCassou>
is there any documentation about the NixOS module system?
<DamienCassou>
I haven't found anything
<eyJhb>
Anyone here using Dropbox?
<energizer>
i'm trying to do a single-file nixos configuration that looks like `{config, pkgs, ...}: config = {}; options = {};` I have `imports=[<home-manager/nixos>];` in both `options` and `config` but I'm getting "The option `home-manager` specified in.. does not exist".
<eyJhb>
energizer: minimal example?
<DamienCassou>
eyJhb: I'm not
<dermetfan>
energizer: imports must not be in options or config but on the top level: `{ imports = …; config = …; options = …; }`
<DamienCassou>
energizer: what is the value of NIX_PATH ?
<eyJhb>
DamienCassou: damn, I think most aren't
<eyJhb>
Maybe I should use Google Drive instead
<DamienCassou>
or some freesoftware such as nextcloud or owncloud
<eyJhb>
https://nixos.wiki/wiki/Dropbox is the origin. I think I have some weird target issues, which stops it from working. Also trying to create a file on start, else Dropbox will bork...
<eyJhb>
I have to clue if there is something obivious, but it won't create the file, and therefore it won't start - https://pastebin.com/vk5myD2V
<rycee>
eyJhb: Did you check the journal entries for the service?
<rycee>
I think the environment variables are necessary.
<eyJhb>
rycee: which ones? I am not running the GUI based, but -cli, everything works except the stupid file :/ Let me check again
<rycee>
Ah, right. But it doesn't write any error message to the log?
<eyJhb>
Not that I know of, let me check again. But does the install/after look right?
<rycee>
No, I don't think any of those targets are available to user services.
<eyJhb>
Damn it
<rycee>
I think you'll want to install it to `default.target`.
<eyJhb>
Any suggestions for the right ones?
<rycee>
Replace `multi-user.target` by `default.target` and remove the `After`.
<eyJhb>
I have NO CLUE how journal gets its date
<eyJhb>
Wait, nvm. I am three days in the future
<eyJhb>
Jun 03 21:51:19 eos aa6xk37xi0bs5jlp6mcjx5wwj6dwmrdl-dropboxInit[10147]: /nix/store/aa6xk37xi0bs5jlp6mcjx5wwj6dwmrdl-dropboxInit: line 7: 10148 Terminated /nix/store/yp00bssrb6c6v2frvl39v58iaq9pm8ci-dropbox-cli-2020.03.04/bin/dropbox start
<eyJhb>
Jun 03 21:51:19 eos systemd[1848]: dropbox@default.service: Control process exited, code=exited, status=143/n/a