Next: Shells, Up: Home Services [Contents][Index]
There are a few essential home services defined in (gnu services)
,
they are mostly for internal use and are required to build a home
environment, but some of them will be useful for the end user.
The service of this type will be instantiated by every home environment automatically by default, there is no need to define it, but someone may want to extend it with a list of pairs to set some environment variables.
(list ("ENV_VAR1" . "value1")
("ENV_VAR2" . "value2"))
The easiest way to extend a service type, without defining a new service
type is to use the simple-service
helper from (gnu services)
.
(simple-service 'some-useful-env-vars-service
home-environment-variables-service-type
`(("LESSHISTFILE" . "$XDG_CACHE_HOME/.lesshst")
("SHELL" . ,(file-append zsh "/bin/zsh"))
("USELESS_VAR" . #f)
("_JAVA_AWT_WM_NONREPARENTING" . #t)))
If you include such a service in you home environment definition, it will add the following content to the setup-environment script (which is expected to be sourced by the login shell):
export LESSHISTFILE=$XDG_CACHE_HOME/.lesshst export SHELL=/gnu/store/2hsg15n644f0glrcbkb1kqknmmqdar03-zsh-5.8/bin/zsh export _JAVA_AWT_WM_NONREPARENTING
注: Make sure that module
(gnu packages shells)
is imported withuse-modules
or any other way, this namespace contains the definition of thezsh
package, which is used in the example above.
The association list (see Association Lists in The GNU Guile Reference manual) is a data structure containing
key-value pairs, for home-environment-variables-service-type
the key
is always a string, the value can be a string, string-valued gexp
(see G-表达式), file-like object (see file-like
object) or boolean. For gexps, the variable will be set to the value of
the gexp; for file-like objects, it will be set to the path of the file in
the store (see 仓库); for #t
, it will export the variable
without any value; and for #f
, it will omit variable.
The service of this type will be instantiated by every home environment automatically, there is no need to define it, but you may want to extend it with a list of packages if you want to install additional packages into your profile. Other services, which need to make some programs available to the user will also extend this service type.
The extension value is just a list of packages:
(list htop vim emacs)
The same approach as simple-service
(see simple-service) for home-environment-variables-service-type
can be
used here, too. Make sure that modules containing the specified packages
are imported with use-modules
. To find a package or information
about its module use guix search
(see Invoking guix package
).
Alternatively, specification->package
can be used to get the package
record from string without importing related module.
There are few more essential services, but users are not expected to extend them.
The root of home services DAG, it generates a folder, which later will be symlinked to ~/.guix-home, it contains configurations, profile with binaries and libraries, and some necessary scripts to glue things together.
The service of this type generates a Guile script, which is expected to be
executed by the login shell. It is only executed if the special flag file
inside XDG_RUNTIME_DIR
hasn’t been created, this prevents redundant
executions of the script if multiple login shells are spawned.
It can be extended with a gexp. However, to autostart an application, users
should not use this service, in most cases it’s better to extend
home-shepherd-service-type
with a Shepherd service (see Shepherd服务), or extend the shell’s startup file with the required command
using the appropriate service type.
The service of this type allows to specify a list of files, which will go to ~/.guix-home/files, usually this directory contains configuration files (to be more precise it contains symlinks to files in /gnu/store), which should be placed in $XDG_CONFIG_DIR or in rare cases in $HOME. It accepts extension values in the following format:
`((".sway/config" ,sway-file-like-object) (".tmux.conf" ,(local-file "./tmux.conf")))
Each nested list contains two values: a subdirectory and file-like object.
After building a home environment ~/.guix-home/files will be
populated with apropiate content and all nested directories will be created
accordingly, however, those files won’t go any further until some other
service will do it. By default a home-symlink-manager-service-type
,
which creates necessary symlinks in home folder to files from
~/.guix-home/files and backs up already existing, but clashing
configs and other things, is a part of essential home services (enabled by
default), but it’s possible to use alternative services to implement more
advanced use cases like read-only home. Feel free to experiment and share
your results.
The service is very similiar to home-files-service-type
(and actually
extends it), but used for defining files, which will go to
~/.guix-home/files/.config, which will be symlinked to
$XDG_CONFIG_DIR by home-symlink-manager-service-type
(for
example) during activation. It accepts extension values in the following
format:
`(("sway/config" ,sway-file-like-object) ;; -> ~/.guix-home/files/.config/sway/config ;; -> $XDG_CONFIG_DIR/sway/config (by symlink-manager) ("tmux/tmux.conf" ,(local-file "./tmux.conf")))
The service of this type generates a guile script, which runs on every
guix home reconfigure
invocation or any other action, which leads
to the activation of the home environment.
The service of this type generates a guile script, which will be executed during activation of home environment, and do a few following steps:
home-files-service-type
,
home-xdg-configuration-files-service-type
and maybe some others),
takes the files from files/.config/ subdirectory and put respective
links in XDG_CONFIG_DIR
. For example symlink for
files/.config/sway/config will end up in
$XDG_CONFIG_DIR/sway/config. The rest files in files/ outside
of files/.config/ subdirectory will be treated slightly different:
symlink will just go to $HOME. files/.some-program/config
will end up in $HOME/.some-program/config.
symlink-manager is a part of essential home services and is enabled and used by default.
Next: Shells, Up: Home Services [Contents][Index]