| 7 | | === System-wide installation (via the OS configuration): |
| 8 | | |
| 9 | | * Makes packages available to all users. |
| 10 | | |
| 11 | | * Best for shared tools or infrastructure software. |
| 12 | | |
| 13 | | === User’s default profile (using guix install): |
| 14 | | |
| 15 | | * Manual and ad hoc. |
| 16 | | |
| 17 | | * Convenient for quickly installing software for personal use. |
| 18 | | |
| 19 | | === Home configuration (via guix home): |
| 20 | | |
| 21 | | * Declarative and portable. |
| 22 | | |
| 23 | | * Ideal for maintaining a consistent user environment across machines. |
| 24 | | |
| 25 | | === Temporary environments (using guix shell): |
| 26 | | |
| 27 | | * Ephemeral, isolated environments for development or experimentation. |
| 28 | | |
| 29 | | * Great for trying out tools without polluting your profiles. |
| 30 | | |
| 31 | | ---- |
| 32 | | |
| 33 | | '''Important:''' Packages only behave well together if they’re installed using the same method. |
| 34 | | |
| 35 | | 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. |
| 36 | | |
| 37 | | Example: |
| 38 | | |
| 39 | | 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. |
| 40 | | |
| 41 | | This becomes especially important when dealing with extensions or plugins. |
| 42 | | 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. |
| 43 | | |
| 51 | | Updated package definitions (e.g., new Guix commit / channel state) |
| 52 | | All required source code (not binaries) |
| 53 | | |
| 54 | | Step 1: On a networked (twin) machine |
| 55 | | a) Check for new versions |
| 56 | | |
| 57 | | guix refresh PACKAGE-NAME |
| 58 | | This will update the local package definition in your channel checkout (if you're maintaining your own channels or overlay packages). |
| 59 | | |
| 60 | | b) Build the package to pull source code into the store |
| 61 | | |
| 62 | | guix build --source PACKAGE-NAME |
| 63 | | This ensures that all source tarballs and patches are downloaded and cached. |
| 64 | | |
| 65 | | c) Export source code and channel state |
| 66 | | |
| 67 | | Export the source derivation (not the binaries!): |
| 68 | | |
| 69 | | guix archive --export -r $(guix build --source PACKAGE-NAME) > sources.nar |
| 70 | | Also export the updated Guix channels or commit used: |
| 71 | | |
| 72 | | guix describe --format=channels > channels.scm |
| 73 | | |
| 74 | | Step 2: Transfer to the air-gapped CI/CD server |
| 75 | | Copy the following files via USB or other air-gap-compliant method: |
| 76 | | |
| 77 | | sources.nar (the archive of source derivations) |
| 78 | | channels.scm (to sync channel state) |
| 79 | | Optionally: your custom channel checkout (if using overlays) |
| 80 | | |
| 81 | | Step 3: On the CI/CD server |
| 82 | | a) Sync channel state |
| 83 | | |
| 84 | | guix time-machine -C channels.scm -- build PACKAGE-NAME |
| 85 | | Or, if you want to pull into your main Guix: |
| 86 | | |
| 87 | | guix pull --channels=channels.scm |
| 88 | | b) Import the sources |
| 89 | | |
| 90 | | guix archive --import < sources.nar |
| 91 | | Now the CI/CD server has all it needs to build the package from source without network access. |
| 92 | | |
| 93 | | Optional: Preload additional sources or dependencies |
| 94 | | To avoid surprises, you may want to pre-fetch all sources recursively: |
| 95 | | |
| 96 | | guix build --sources=transitive PACKAGE-NAME |
| 97 | | guix archive --export -r $(guix build --sources=transitive PACKAGE-NAME) > all-sources.nar |
| 98 | | This ensures no source fetch attempts will occur during CI builds. |
