8.5 KiB
RekahSoft Dotfiles
These are the dotfiles of the author, managed using guix-home, in combination with gnu stow (until the gnu stow deployment mechanism has been deprecated in preference of guix-home).
Repository Structure
-
channels.scm
- Guix Channel File
-
.gitignore
- Files ignored by git
-
.guix/
- Guix channel directory
-
.guix-authorizations
- Guix authorizations file1
-
.guix-channel
- Guix channel file2
-
README.org
- Org-mode3 documentation
-
TODO.org
- Org-mode todo's, known issues and future aspirations
-
home-manifest.scm
- Guix manifest used for cuirass builds (and as needed via the cli)
-
user-config
- Configuration for various programs managed using a combination of gnu stow and guix-home
Guix Channel File
Guix channels4 allow for Guix to be customized and extended. They are also critical for
replicating a Guix system5. To ensure reproducibility, a channels.scm
file is provided
in this repository that is expected to be used during deployment. It pins external guix
channels to specific versions.
TODO Updating guix channels used for deployment
This doesn't work right unless your channels match what is expected by this repository.
guix time-machine -- describe -f channels > channels.scm
dotfiles
the Guix Channel
This repository is itself a Guix channel, which allows home configurations to come directly from the channel, and the version of this configuration be managed just like any other guix channel. It also facilitates CI, allowing for changes this channel be evaluated by Cuirass at https://guix-ci.home.rekahsoft.ca6. This channel does not define any packages, only home configurations.
Quickstart
TODO Legacy Configuration
Configurations for a variety of programs are available to be 'installed' by symbolically
linking them into $HOME
using stow. This process is simplified by the provided Makefile
,
however is expected to be deprecated by the switch to Guix home, which is not yet fully
completed. Currently guix home only manages bash configuration, and all other configuration
is still managed using the 'legacy' stow method described here.
# See what will be installed/linked by stow
make DRY=true
# Install/link all configurations
make
TODO Makefile Usage
Makefile
is expected to be become unnecessary after this configuration is managed by Guix home instead of using stow.
make [packages] [DRY=true] [RESTOW=true] [DELETE=true]
Where: <DRY> must be undfined or 'true' <RESTOW> must be undfined or 'true' <DELETE> must be undfined or 'true'
Notes: If no [packages] are listed, all packages are actioned upon via the all target
Examples
# Install a subset of the entire configuration
make zsh xorg
# Relink configuration
make RESTOW=true
# Relink configuration for a subset of packages
make RESTOW=true bash zsh
# Uninstall/unlink configuration
make DELETE=true
# Uninstall/unlink configuration for a subset of packages
make DELETE=true bash
Working with Local Sources
Clone this repository.
git clone <repo> ~/.dotfiles
cd ~/.dotfiles
This home configuration is presented as a guix channel, and because of this, changes normally
need to be committed in order to be tested. However, the -L|--load-path
option to guix can
be used to explicitly reference this repositories' uncommitted channel sources in .guix
(using -L .guix
).
Additionally, to test with a different set of channels (for example, to check if this home
configuration works following updates to the guix, nonguix or some other dependent channel),
guix time-machine
can be used, explicitly referencing a channel file with -C|--channel
.
When ones local guix channels match channels.scm
, guix time-machine ...
does not need to
be used because it has no effect and just adds overhead.
TODO
Issues when using -L|--load-path
along with guix time-machine
I have found that source changes are not detected when using guix time-machine -C
channels.scm -- <CMD>
when <CMD>
uses the -L|--load-path
option. However, guix <CMD>
on its own does detect source changes.
It's worth noting that I've missed this before because I think that when using guix
time-machine
with -L
the source is still parsed/evaluated, so syntax errors are detected.
This needs to be further investigated and is likely a guix bug.
Another note: It appears that if -L
is provided on both sides of the guix time-machine
command, it works as expected and detects source changes. This does not appear to be
consistent though, and sometimes using -L
only on the rhs works as expected.
Deploy
guix time-machine -C channels.scm -- home reconfigure -L .guix -e '(@ (rekahsoft guix-config home) %home)'
Build
guix time-machine -C channels.scm -- home build -L .guix -e '(@ (rekahsoft guix-config home) %home)'
Test in a container
guix time-machine -C channels.scm -- home container -L .guix -e '(@ (rekahsoft guix-config home) %home)'
View Guix Extension Graph
guix home extension-graph -e '(@ (rekahsoft guix-config home) %home)' | guix shell gnome-icon-theme xdot -- xdot -
View Shepherd Graph
guix home shepherd-graph -e '(@ (rekahsoft guix-config home) %home)' | guix shell gnome-icon-theme xdot -- xdot -
Development
This section details some useful tips regarding development.
Guix
Here are some useful commands for working with package upgrades on guix.
# Check for binary substitute availability on the tip of master
guix time-machine -- weather -m ~/.dotfiles/home-manifest.scm
# Build a environment using the provided home-manifest.scm off the tip of master (useful to test the new environment)
guix time-machine -- environment -m ~/.dotfiles/home-manifest.scm -- exit
Updates that modify zsh site-functions (completions)
These updates require additional manual effort, otherwise completions don't show up.
# Set fpath in ~/.zprofile (this is already done in the zsh configuration)
#fpath=(~/.guix-home/profile/share/zsh/site-functions $fpath)
rm -r ~/.zcompdump && compinit
Try out any packaged window manager
The included xorg
configuration provides a script that is used to startx
, located in
~/.bin/startx.sh
after installing/linking the xorg
configuration. This script is required
as the startx
that comes with the xinit
package on guix does not work when Xorg is
installed in a user profile. Like the original startx
command, this script passes through
arguments to ~/.xinitrc
. The included ~/.xinitrc
takes two optional arguments,
SESSION_WM
and SESSION_TYPE
, the window manager to run and the session type to use. The
session type can be one of full
(default), min
, or new
.
Start the default window manager (exwm
) with the default session type (full
).
startx
Note: if using the configuration zsh
or bash
, all *.sh
scripts linked into ~/.bin
are aliased to exclude the .sh
suffix.
guix shell ratpoison -- startx.sh ratpoison new
Note: The script startx.sh
must be used directly here, and not
by the startx
alias mentioned above.
This works very well for simple window managers, however for more complicated environments, many times there are numerous packages that will be required. Here is an example of starting xfce using this mechanism.
guix shell xfce xfce4-session xfconf -- startx.sh startxfce4 new