92 lines
4.8 KiB
YAML
92 lines
4.8 KiB
YAML
uuid:
|
|
- value: d753217f-2d8f-431d-850c-d54597b46b76
|
|
langcode:
|
|
- value: en
|
|
type:
|
|
- target_id: daily_email
|
|
target_type: node_type
|
|
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
|
|
revision_timestamp:
|
|
- value: '2025-05-11T09:00:02+00:00'
|
|
revision_uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
revision_log: { }
|
|
status:
|
|
- value: true
|
|
uid:
|
|
- target_type: user
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
|
title:
|
|
- value: 'Why I use nixpkgs-unstable'
|
|
created:
|
|
- value: '2025-01-22T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:02+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2025/01/22/nixpkgs-unstable
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p>In the majority of my <code>flake.nix</code> files, such as the one <a href="/daily/2025/01/19/minimum-viable-development-environment">I've been experimenting with for Drupal projects</a>, I use <code>nixpkgs-unstable</code> as my primary input.</p>
|
|
|
|
<p>The nixpkgs package manager has two major releases a year, in May and November, which would be 24.05 and 24.11 for 2024 respectively.</p>
|
|
|
|
<p>Using <code>nixpkgs-unstable</code>, I get the latest packages and NixOS options and don't need to wait for the next major stable release.</p>
|
|
|
|
<p>But doesn't that make things more likely to break when updating?</p>
|
|
|
|
<p>The number of backwards incompatible changes and breakages on unstable are minimal, but I'd rather deal with small issues and updates regularly rather than only twice a year.</p>
|
|
|
|
<p>Small updates more often are better, in my opinion.</p>
|
|
|
|
<p>But, what if there is an issue with a package that I'm using, such as a build issue, regression or incompatibility?</p>
|
|
|
|
<p>With flakes, I can import multiple versions of nixpkgs in the same configuration and use them where the configuration I need to.</p>
|
|
|
|
<p>I need to in one project, I've added an input with nixpkgs pinned to a specific Git commit in the nixpkgs repository as some packages are using outdated versions and are no longer present in the latest releases.</p>
|
|
|
|
<p>It's not all or nothing, I can pick which packages to be unstable and which I want to use stable or use older versions.</p>
|
|
|
|
<p>See <a href="https://code.oliverdavies.uk/opdavies/dotfiles/src/commit/a5c1c891020c5026ca1c2d83afd6cbe8002a136c/flake.nix">my dotfiles repository</a> for an example, where I have four versions of nixpkgs imported - including unstable and master, which is even newer.</p>
|
|
|
|
<p>Every input is still locked in the <code>flake.lock</code> file, so everything is still reproducible whichever versions of nixpkgs I decide to use.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>In the majority of my <code>flake.nix</code> files, such as the one <a href="/daily/2025/01/19/minimum-viable-development-environment">I've been experimenting with for Drupal projects</a>, I use <code>nixpkgs-unstable</code> as my primary input.</p>
|
|
|
|
<p>The nixpkgs package manager has two major releases a year, in May and November, which would be 24.05 and 24.11 for 2024 respectively.</p>
|
|
|
|
<p>Using <code>nixpkgs-unstable</code>, I get the latest packages and NixOS options and don't need to wait for the next major stable release.</p>
|
|
|
|
<p>But doesn't that make things more likely to break when updating?</p>
|
|
|
|
<p>The number of backwards incompatible changes and breakages on unstable are minimal, but I'd rather deal with small issues and updates regularly rather than only twice a year.</p>
|
|
|
|
<p>Small updates more often are better, in my opinion.</p>
|
|
|
|
<p>But, what if there is an issue with a package that I'm using, such as a build issue, regression or incompatibility?</p>
|
|
|
|
<p>With flakes, I can import multiple versions of nixpkgs in the same configuration and use them where the configuration I need to.</p>
|
|
|
|
<p>I need to in one project, I've added an input with nixpkgs pinned to a specific Git commit in the nixpkgs repository as some packages are using outdated versions and are no longer present in the latest releases.</p>
|
|
|
|
<p>It's not all or nothing, I can pick which packages to be unstable and which I want to use stable or use older versions.</p>
|
|
|
|
<p>See <a href="https://code.oliverdavies.uk/opdavies/dotfiles/src/commit/a5c1c891020c5026ca1c2d83afd6cbe8002a136c/flake.nix">my dotfiles repository</a> for an example, where I have four versions of nixpkgs imported - including unstable and master, which is even newer.</p>
|
|
|
|
<p>Every input is still locked in the <code>flake.lock</code> file, so everything is still reproducible whichever versions of nixpkgs I decide to use.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|