cc @Profpatsch (might be of interest to you?)

seems like a good idea. This sadly has broken the xmonad test in nixos/tests because it depended on this "broken" behavior. Would be nice of you if you could fix it also :)

Hmm the test is actually tricky. It uses launch which does not support the xmonad command line options..
There probably was a reason why launch was used instead of the standard xmonad entry point, but lets see.

(I can't run the tests locally atm because qemu is broken on my hardware – gives me a kernel panic)

Ok, I finally found machine with working qemu. The test won't work as is, essentially because it tests precisely the old behavior (which makes me think that somebody wanted it?). Using the standard xmonad entry point fails because that makes wrong assumptions about the binary name, using launch would require reimplementing some logic from the xmonad module, which I would rather not do for a simple test.

Actually my favorite solution for this problem would be to just drop that part of the test. Maybe have a second test that actually tests the code path without custom config.

I finally found a way to make the test work while staying close to the original version. It does test restarting as the original test did (at least I think that was the intention). Just have to be careful to avoid shelling out to xmonad --restart which will not work with launch..

(fixed a type in the commit message)

Ok, so I now understand why people might want the vanilla xmonad in their PATH:

The standard keybinding for restarting xmonad actually goes through a somewhat convoluted process (detailed in this discussion), which involves executing the xmonad from PATH and makes assumptions about it, namely that it uses the xmonad entry point.

But if people use launch as entry point (the example actually advertises this), putting the configured binary in path will break that key binding.
I think its still more consistent to have the configured xmonad in PATH, as this

• avoids accidentally dropping you into an vanilla xmonad (without any config) by not overwriting and pressing the standard mod+q key binding
• allows you to restart into the new xmonad after rebuilding your system by adding a key binding that calls restart "xmonad" True

But the module description / docs could be improved somewhat in this regard ;-) will look into that..

The one thing I am still worried about a bit is that some people may rely on the following workflow atm:
configure xmonad with nixos + config but have a copy of that xmonad.hs in .xmonad
-> change that local copy, use mod+q to recompile and exec into it
-> when you are satisfied with the result, copy+paste that into your nixos config
That workflow can be saved by making your own binary do the recompilation / exec on startup, but requires significantly more insight than previously.

Apart from what this pr does there are two other other sensible approaches I can think of in the case of xmonad configured through the config module option:

• put nothing into PATH, but put both xmonad versions in a read only variable of the module: This will avoid accidentally dropping ppl into unconfigured xmonad, if they want either the old behavior or the one from this pr, they can explicitly put either one or the other in PATH
• put both in PATH but under different names (say xmonad and xmonad-configured). Can still accidentally dropping ppl into unconfigured xmonad, but also allows users to restart into xmonad-configured if they want.

@Lassulus ah I looked through the history of this module, and you actually submitted the original pr for the config option (thanks by the way!); after reading that, I think it wasn't intentional to put the plain xmonad in PATH, right?

The one thing I am still worried about a bit is that some people may rely on the following workflow atm

^ It occurs to me now, that you can also always just temporarily disable the config option, use plain xmonad with recompilation semantics, and re-enable it afterwards...

Pushed some docs. Is there a known way to show inline code, in such a way that there is a visible difference to ordinary text in man configuration.nix? I tried <code></code> and it failed me :-/

Apart from that I think I am now happy with the state of this pr.

(fixed up a remnant from some early experimentation in the nixos test)

no, putting the original xmonad was indeed not intentional, but never bothered me enough to actually change it. While you are on it. Maybe you can add some maintainers to the service while you are on it? (like you and me for example)
And thanks for your contribution :)

before merging this @NeQuissimus might want to have a look, because he is listed as maintainer of the xmonad test (just noticed)

I think I adopted the test at one point when it was broken. I don't really remember though :D I do use XMonad, so I appreciate this!

This fixes configuration not updating after recompiling & restarting? Appreciate it.

I don’t change my config often enough to particularly care, but great to see it works now!

The one thing I am still worried about a bit is that some people may rely on the following workflow atm:
configure xmonad with nixos + config but have a copy of that xmonad.hs in .xmonad
-> change that local copy, use mod+q to recompile and exec into it
-> when you are satisfied with the result, copy+paste that into your nixos config

@xaverdh That's precisely the workflow I was using. It's not ideal, but when I'm making frequent changes to my config it's a quick way to try things out.

Thanks for providing the example compileRestart function. I found that in order to get it working, I had to add the following to my environment.systemPackages:

(haskellPackages.ghcWithPackages (ps: with ps; [xmonad xmonad-contrib]))

Is that expected? I ask because I didn't need to do this previously, and while I don't mind adding it, I'd like to better understand what changed.

Thanks for providing the example compileRestart function. I found that in order to get it working, I had to add the following to my environment.systemPackages:

(haskellPackages.ghcWithPackages (ps: with ps; [xmonad xmonad-contrib]))

Is that expected? I ask because I didn't need to do this previously, and while I don't mind adding it, I'd like to better understand what changed.

Yes that's actually expected (probably should've added that to the docs as well).

The vanilla xmonad has a wrapper, that puts ghc in place. Now prior to this pr, the running xmonad with config used to exec the xmonad from PATH (i.e. the vanilla one), which then in turn did the recompilation and executed the newly compiled binary. So the compiling was done by the vanilla version, which had knowledge of ghc and friends due to the wrapper.

Now in your setup the xmonad with config does not do the double exec but rather does the recompilation step directly, so it will not know about ghc, unless you put it in PATH.