<tudorr>
and i want them to override executables from the nix profile
<eyJhb>
Then use sessionVariables = { PATH = "mydir:$PATH" }
hmpffff_ has quit [Quit: nchrrrr…]
Bunogi has quit [Ping timeout: 258 seconds]
Bunogi has joined #home-manager
evanjs has quit [Read error: Connection reset by peer]
evanjs has joined #home-manager
cole-h has joined #home-manager
MmeQuignon has joined #home-manager
DamienCassou1 has joined #home-manager
<DamienCassou1>
hi
<DamienCassou1>
I've seen there is no service for borgbackup
<DamienCassou1>
there is one in NixOS though
<DamienCassou1>
I could just copy/paste the service from NixOS to home-manager but I find it quite bad because the file is quite large
<DamienCassou1>
is there a better way to enjoy this service in home-manager without NixOS?
<__monty__>
That doesn't work. You can't simply drop a NixOS module into home-manager.
hmpffff has joined #home-manager
<DamienCassou1>
I know some editing is necessary after copy/pasting. Is there a better way than doing all this work? For example, has anyone ever tried to refactor a NixOS module so it can be imported in home-manager with minimal effort?
<DamienCassou1>
for example, the configuration options would be the same, the generated bash scripts would be the same
<tudorr>
eyJhb: that's exactly what i did and it doesn't work
<tudorr>
it always puts ~/.nix-profile/bin first in PATH
<DamienCassou1>
tudorr: you may do it the other way around: make home-manager install your scripts itself: said differently, stop asking home-manager to install the programs you want to wrap but ask it to install the wrapping scripts instead
<tudorr>
well i made home-manager install the wrapping scripts in ~/wrappers/
<tudorr>
because otherwise it conflicts with the actual packages it wraps
<tudorr>
and i need to add ~/wrappers to PATH
<tudorr>
for example, i have home-manager generate a script to wrap emacs to start it with some environment variables. the script it also named emacs
<tudorr>
DamienCassou1: is there any way to make it not clash with the actual executables?
<DamienCassou1>
tudorr: don't ask home-manager to add Emacs to your path.
<DamienCassou1>
home-manager has home.packages. If you find where you add the original Emacs package to home.packages, you might find a way to have home-manager not add it
<tudorr>
well i want home-manager to install emacs. my problem is also not emacs-related.
<rycee>
tudorr: Try adding a `meta.priority` attribute to your wrapper package.
<DamienCassou1>
Emacs will be a dependency of your wrapping script so Emacs will be installed. But, if it is not in home.packages, it won't be added to your PATH. Only the wrapping script will
<tudorr>
rycee: how can i make it a package? it's not currently a package, i use home.file."filename"
<DamienCassou1>
rycee: do you have any idea for having borgbackup through home-manager instead of through NixOS? I'm planning to switch from NixOS to Fedora to check if my hardware issues are fixed there. I will try to live without NixOS but I will have a hard time living without nix and home-manager
<DamienCassou1>
tudorr: look at this example: this makes a package out of a shell script in the same directory
<DamienCassou1>
tudorr: then you can use Nix overlay mechanism to add the definition of your new package to `pkgs`
<rycee>
Damien Cassou: Not in any easy way that I can think of. Possibly it would be achievable to import the NixOS version of the module and use the `options` attribute in a HM module and then implement the `config` attribute yourself.
<DamienCassou1>
the problem is that this module has a lot of private functions in a `let` form that are used to generate the the bash script that does the backup. I thought about refactoring the NixOS module in a way that more than the `options` attribute can be reused
<rycee>
I think the realistic option is to copy the file and adjusting as necessary :-/
<DamienCassou1>
this won't make it possible to just reuse the module as it is (e.g., the systemd service will be different at least), but it should help
<DamienCassou1>
this is realistic today but the script is quite large and it will require maintenance :-(
<DamienCassou1>
thanks for your answer. I think it's really bad that home-manager needs to duplicate. But you are probably right
<rycee>
Attempting to pull in modules from NixOS is a recipe for headaches, there were a few such modules early in the life of HM but it kept breaking a lot since people change the module in NixOS without considering HM.
<rycee>
Which is quite natural, the NixOS modules are not intended as APIs for other projects so they cannot be expected to behave like that.
<rycee>
The two remaining modules in HM that are pulled from `<nixpkgs>` are the assertions and meta modules which are very stable.
<rycee>
HM also used to pull in the documentation generation framework from `<nixpkgs>` and that also broke a lot so at some point I copied it over into HM and then later broke out into it's own project, nmd.
<tudorr>
rycee: i tried to use pkgs.runCommand and it would error saying "cannot move '/nix/store/.../bin/emacs' to '/nix/store/.../bin/.emacs-wrapped': permission denied"
<tudorr>
my build script is `mkdir -p $out/bin; wrapProgram "${pkgs.emacs}/bin/emacs" --set FONTCONFIG_FILE=${pkgs.fontconfig.out}/etc/fonts/fonts.conf`
<rycee>
tudorr: Right, `wrapProgram` moves the executable it wraps. You'll need to use `makeWrapper` directly.
<DamienCassou1>
rycee: thank you very much for your input. I needed it. I will try again to copy/paste and adapt the result. This is quite tedious but important
<rycee>
Damien Cassou: I think the final paragraph is something like what you are needing, if you replace postgres by borgbackup.
<rycee>
tudorr: It makes the wrapped program think it is having that name. In this case it actually shouldn't be needed so you can probably skip it.
<tudorr>
ok it worked
<tudorr>
but it needs one last thing
<rycee>
tudorr: Since the emacs binary that actually is run is having the name "emacs".
<tudorr>
i want emacs (and any other wrapped program) to be run by nixGL
<tudorr>
can i tell makeWrapper to add args to a program?
<tudorr>
i couldn't find any docs on makeWrapper's flags
<rycee>
tudorr: Right, then I guess you actually want to wrap nixGL and not emacs.
<tudorr>
yes no problem in that i managed to get a hold of its derivation
<tudorr>
but i want to generate wrapper scripts for various programs, including emacs, to be called by nixgl and with the FONTCONFIG_FILE var set correctly
<tudorr>
the makeWrapper approach works well but i need a way to tell it to append the path to emacs as an argument to nixgl
<tudorr>
i think --add-flags should do it?
<rycee>
Yes, --add-flags is the thing to use for that.
quinn has quit [Ping timeout: 256 seconds]
<rycee>
tudorr: If you want to do it for all installed executables or a large subset of them then it might be easier to just do all of them at once through `home.extraProfileCommands`.
<tudorr>
i want to do it only for graphical applications installed through home-manager, so it should be fine
<tudorr>
i have an option declared that given some programs, it generated the packages with wrapper scripts
<rycee>
Right, sounds like a good idea. The only concern would be if something would like to start, e.g., emacs directly from its Nix store path. To resolve that I think the only solution would be to do the overlay thing.
<eyJhb>
rycee: is there anything obivious wrong here ? Or might it be upstreamed? - https://termbin.com/6xii
<tudorr>
ohhh yesss it worked
<tudorr>
thanks so much rycee!
<tudorr>
i have achieved graphical apps managed by home-manager on a non-nixos os with this, are there any other approaches?
<rycee>
tudorr: Sorry, no idea. Maybe somebody in #nixos knows?
<rycee>
eyJhb: Use `lib.hm.dag` instead of `config.lib.dag`.
<rycee>
eyJhb: Put empty line between option definitions, otherwise it becomes a wall of text.
<rycee>
eyJhb: I don't understand what the `baseDir` stuff is about. E.g., you need both `~/${baseDir}/.dropbox` and `~/.dropbox`?
<eyJhb>
rycee: ahh, you see my friend! It is because Dropbox is ... I cannot write the word, some might get offended
<tudorr>
rycee: btw what overlay thing are you talking about?
<eyJhb>
But becacuse Dropbox requires the folder to be named Dropbox, but I want it to be named anything. Therefore I create a dir ~/.dropbox-hm, with the required folders (.dropbox, .dropbox-dist and Dropbox) and set it as HOME for Dropbox in systemd
dermetfan has quit [Ping timeout: 256 seconds]
<eyJhb>
That way I can symlink to baseDir (.dropbox-hm), and have the folder named and placed whereever I want
makefu has joined #home-manager
<eyJhb>
Does that somewhat make sense rycee ?
dermetfan has joined #home-manager
<makefu>
hey all, i am currently facing the issue that i want to override a package used inside home-manager modules via my own overlay. however it seems that the overriding with my overlay does not affect which package is used by home-manager. more explicitly i want to use my own flameshot package and i tried to load my version via my own overlay.
<makefu>
what would be the 'correct' way to use my overlayed package instead of the default ones to be used in home-manager?
<rycee>
eyJhb: Right, yeah I guess that makes sense. But do you then need ~/.dropbox and ~/.dropbox-dist?
<eyJhb>
rycee: without them, you cannot run the dropbox command, as it uses the $HOME that you have, to find the PID to connect to the daemen
<eyJhb>
Maybe I can remove .dropbox-dist
<rycee>
makefu: How do you define your overlay?
<rycee>
makefu: Through `nixpkgs.overlays`?
<eyJhb>
rycee: in ` default = "${config.home.homeDirectory}/Dropbox";`, do I actually need config.home.homeDirectory? Also,what is the correct way to check for the autostart and only run the code then?
<eyJhb>
Ignore the last part, I will read further on that, but first part is relevant
<makefu>
rycee: i include home-manager via nix-path essentially and import it via imports = [ <home-manager/nixos> ]
<makefu>
the overlays i define via nixpkgs.overlays, yes
<rycee>
makefu: Ok, through the system configuration's `nixpkgs.overlays` or your user configuration's `nixpkgs.overlays`? The system one will not be visible to the user configuration by default.
<makefu>
i am currently using the system one, however i am also only using the home-manager system configuration.
<rycee>
eyJhb: I guess it depends on whether it should be possible to place the Dropbox directory outside $HOME. If not then you could use a relative path and add the `${config.home.homeDirectory}` part in the activation block.
<rycee>
makefu: I take that to mean that you have something like `nixpkgs.overlays = [ … ]; home-manager.users.makefu = …` If so you either need to also add the overlay into the user's configuration. Or add `home-manager.useGlobalPkgs = true` to the system configuration.
<makefu>
the second one sounds great, i give it a try
<rycee>
The latter will make HM use the system level `pkgs` inside the user configuration.
<rycee>
Which should be ok in most cases but it does make the `nixpkgs.*` options inside the user's configuration inoperable.
<makefu>
right now i am going nixos system-configuration so this is fine for me at least :)
<__monty__>
DamienCassou1: If you're porting the borg module to HM, please improve it, a lot, thank you.
<makefu>
that worked! thanks so much rycee!
<rycee>
makefu: np :-)
<rycee>
eyJhb: Since you are defining a service then `services.dropbox` seems more appropriate.
<eyJhb>
rycee: I assume "dropbox-testing" as the activation script should be dropbox instead? :p
<eyJhb>
rycee: removing the autostart, seems off tbh.
<hpfr[m]>
is it possible to use the dconf module with gnome? I ran `dconf update` and got no file `/etc/dconf/db`.
<hpfr[m]>
whoops, I forgot the enable option. but should I use dconf on gnome when there's already gsettings? I want to declaratively manage things but idk if that's a bad idea
<rycee>
hpfr: Should be fine to use dconf.
<rycee>
`dconf watch` is handy to see which paths to set.
<rycee>
eyJhb: Should be fine for a PR. There are a few other things that could be fixed but I can add those as comments in the PR.
<hpfr[m]>
rycee: oh you can use that to see what the GUI settings app does? sweet. unfortunately I tried to set `settings."org/gnome/desktop/session".idle-delay = "uint32 0";` which is not in the GUI afaik but after trying `gsettings get org.gnome.desktop.session idle-delay` it's still 300
<rycee>
hpfr: That will try setting idle-delay to a string "uint32 0".