Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: NixOS/nixpkgs
base: 80e3ca6f4afd
Choose a base ref
...
head repository: NixOS/nixpkgs
compare: b90c5cb703da
Choose a head ref
  • 1 commit
  • 1 file changed
  • 1 contributor

Commits on Dec 28, 2020

  1. XMonad: configured recompile (#107696)

    * nixos/xmonad: xmonad config w/ghc+xmessage
    
    When the "config" option isn't set, we use xmonad-with-packages to
    provide xmonad with runtime access to an isolated ghc, ensuring it can
    recompile and exec a user's local config (e.g. $HOME/.xmonad/xmonad.hs)
    regardless of which ghc (if any) is on PATH.
    
    When the "config" option is set, however, we compile a configured xmonad
    executable upfront (during nixos-rebuild), and prior to this commit, it
    was not provided with runtime access to an isolated ghc.
    
    As a result, with the "config" option set, it was not possible
    to recompile and exec a user's local config unless there was a
    compatible version of ghc on PATH with the necessary packages (xmonad,
    xmonad-contrib, etc.) in its package database. Adding such a ghc to
    environment.systemPackages, e.g.
    
      (haskellPackages.ghcWithPackages (ps: with ps; [xmonad xmonad-contrib]))
    
    is problematic because it adds both ghc and an unconfigured xmonad to
    PATH, e.g.
    
      $ ls -l $(which xmonad ghc)
      lrwxrwxrwx ... /run/current-system/sw/bin/ghc -> /nix/store/...-ghc-8.10.2-with-packages/bin/ghc
      lrwxrwxrwx ... /run/current-system/sw/bin/xmonad -> /nix/store/...-ghc-8.10.2-with-packages/bin/xmonad
    
    Having the unconfigured xmonad on PATH is particularly bad because
    restarting xmonad will dump the user into the unconfigured version, and
    if no local config exists (e.g. in $HOME/.xmonad/xmonad.hs), they'll be
    left in this unconfigured state.
    
    In this commmit, we give the configured xmonad runtime access to ghc
    like xmonad-with-packages does for the unconfigured version. The aim
    is to allow the user to switch between the nixos module's config and a
    local config (e.g. $HOME/.xmonad/xmonad.hs) at will, so they can try out
    config changes without performing a nixos-rebuild.
    
    Since the xmonad on PATH is the configured executable, there's no
    danger a user could unwittingly restart into the unconfigured version,
    and because xmonad will refuse to recompile when no local config
    exists, there's no danger a user could unwittingly recompile into an
    unconfigured version.
    
    Given that a local config exists, the recompile/restart behavior depends
    on two factors:
    - which entry point is used
      * 'XMonad.xmonad' (default)
      * 'XMonad.launch' (recommended in "config" option description)
    - what operation is triggered (i.e. via mod+q)
      * `spawn "xmonad --recompile && xmonad --restart"` (default)
      * `restart "xmonad" True`
      * custom function
    
    If the default 'XMonad.xmonad' entrypoint and default mod+q operation
    are used, hitting mod+q will compile and exec the local config, which
    will remain in use until next time the display manager is restarted.
    
    If the entrypoint is changed to 'XMonad.launch' but mod+q left with its
    default operation, hitting mod+q will have no visible effect. The logs
    (as seen by running `journalctl --identifier xmonad --follow`) will show
    an error,
      X Error of failed request:  BadAccess (attempt to access private resource denied)
    which indicates that the shell was unable to start xmonad because
    another window manager is already running (namely, the nixos-configured
    xmonad).
    https://wiki.haskell.org/Xmonad/Frequently_asked_questions#X_Error_of_failed_request:_BadAccess_.28attempt_to_access_private_resource_denied.29
    
    Changing the mod+q operation to `restart "xmonad" True` (as recommended
    in the "config" option's description) will allow a restart of the
    nixos-configured xmonad to be triggeredy by hitting mod+q.
    
    Finally, if the entrypoint is 'XMonad.launch', mod+q has been
    bound to `restart "xmonad" True` and another key bound to a custom
    recompile/restart function (e.g. `compileRestart` as shown in the
    "config" option example), the user can switch between the nixos module's
    config and their local config, with the custom key switching to the
    local config and mod+q switching back.
    
    * nixos/xmonad: refactor let binding
    
    * nixos/xmonad: refactor (eliminate duplicate code)
    
    * nixos/xmonad: install man pages
    
    Prior to this commit, man pages were not installed if the "config"
    option was set.
    
    * nixos/xmonad: comment grammar fixups
    
    * nixos/xmonad: writeStateToFile in example config
    
    Calling writeStateToFile prior to recompiling and restarting allows
    state (workspaces, etc.) to be preserved across the restart.
    
    * nixos/xmonad: add ivanbrennan to maintainers
    
    * nixos/xmonad: adjust compileRestart example
    
    * nixos/xmonad: add missing import to example config
    ivanbrennan committed Dec 28, 2020
    Copy the full SHA
    b90c5cb View commit details
    Browse the repository at this point in the history