== Profiles and home configuration

'''Question:''' I’ve heard there are different ways to install or declare packages in Guix. What are the use cases, and what are the pros and cons?

'''Answer:''' Yes, Guix supports [[multiple ways to install and manage software packages]], each with its own use case:

=== System-wide installation (via the OS configuration):

* Makes packages available to all users.

* Best for shared tools or infrastructure software.

=== User’s default profile (using guix install):

* Manual and ad hoc.

* Convenient for quickly installing software for personal use.

=== Home configuration (via guix home):

* Declarative and portable.

* Ideal for maintaining a consistent user environment across machines.

=== Temporary environments (using guix shell):

* Ephemeral, isolated environments for development or experimentation.

* Great for trying out tools without polluting your profiles.

----

'''Important:''' Packages only behave well together if they’re installed using the same method.

If the same package is installed via multiple methods (e.g., system + user profile), only one will be used, and it will shadow the others.

Example:

Suppose vim is installed system-wide. If a user then installs their own version of vim in their default profile, that version will shadow the system version. If they also declare vim in their guix home configuration, it will shadow both the system and user-installed versions.

This becomes especially important when dealing with extensions or plugins.
For example, if vim-nerdtree is installed system-wide, but the user is using a vim from their home or user profile, the system-installed plugin might not work — because it’s tied to the shadowed version of vim.

== CI / CD

Q: How can I ensure newer package versions are available on my air-gapped CI/CD server (and build them there)?

A:
If you want to build everything from source on the CI/CD server, you must transfer:

Updated package definitions (e.g., new Guix commit / channel state)
All required source code (not binaries)

Step 1: On a networked (twin) machine
a) Check for new versions

guix refresh PACKAGE-NAME
This will update the local package definition in your channel checkout (if you're maintaining your own channels or overlay packages).

b) Build the package to pull source code into the store

guix build --source PACKAGE-NAME
This ensures that all source tarballs and patches are downloaded and cached.

c) Export source code and channel state

Export the source derivation (not the binaries!):

guix archive --export -r $(guix build --source PACKAGE-NAME) > sources.nar
Also export the updated Guix channels or commit used:

guix describe --format=channels > channels.scm

Step 2: Transfer to the air-gapped CI/CD server
Copy the following files via USB or other air-gap-compliant method:

sources.nar (the archive of source derivations)
channels.scm (to sync channel state)
Optionally: your custom channel checkout (if using overlays)

Step 3: On the CI/CD server
a) Sync channel state

guix time-machine -C channels.scm -- build PACKAGE-NAME
Or, if you want to pull into your main Guix:

guix pull --channels=channels.scm
b) Import the sources

guix archive --import < sources.nar
Now the CI/CD server has all it needs to build the package from source without network access.

Optional: Preload additional sources or dependencies
To avoid surprises, you may want to pre-fetch all sources recursively:

guix build --sources=transitive PACKAGE-NAME
guix archive --export -r $(guix build --sources=transitive PACKAGE-NAME) > all-sources.nar
This ensures no source fetch attempts will occur during CI builds.

[WikiStart Back]