unify versioning #279

New issue

Closed

opened 2025-03-25 09:32:59 +01:00 by kiara · 2 comments

kiara commented

2025-03-25 09:32:59 +01:00

Owner

right now, we manage dependency versions using:

flakes
npins

this currently allows discrepancies in versions used in e.g. local development vs deployed services, essentially breaking our reproducibility.

at #274, i stumbled upon a versioning discrepancy now with our demo environment being passed a nixpkgs instance from our flake (offering e.g. opentofu 1.8.7), whereas some of our development shells have used an instance from npins (offering opentofu 1.8.5, used in a dev shell's tofu init).

launch/tf.nix
- panel/env.nix
  - panel/default.nix
    - infra/machines/fedi201/fedipanel.nix (1.8.7: flake)
  - panel/nix/configuration.nix
- panel/nix/package.nix
  - panel/default.nix
    - infra/machines/fedi201/fedipanel.nix (1.8.7: flake)
  - panel/nix/configuration.nix
    - panel/default.nix
      - infra/machines/fedi201/fedipanel.nix (1.8.7: flake)
- launch/default.nix: shell (1.8.5: npins)

note that there have been various reasons for how this came about:

flake.nix: used as nixops wants flake outputs
- nixpkgs: used as flake-parts' system isn't explicitly known in infra/flake-part.nix to instantiate an npins nixpkgs
npins/sources.json: used as @fricklerhandwerk used it and we opted to make a distinct shell for the panel
- nixpkgs: taken from npins as consuming this from flake seems more involved

note that there have been multiple barriers toward potentially replacing flakes (tho at least they can import one another's):

outputs
- nixops4 using this (#309)
- ~~[ ] nixos-anywhere TF's special_args only supporting flakes so far~~ - superseded by #307
inputs
- importing modules exposed this way from without flakes would need rework
- instantiating nixpkgs from npins wants a system, whereas we haven't had this exposed in our flake parts
- npins double downloading bug

right now, we manage dependency versions using: - flakes - npins this currently allows discrepancies in versions used in e.g. local development vs deployed services, essentially breaking our reproducibility. at #274, i stumbled upon a versioning discrepancy now with our demo environment being passed a nixpkgs instance from our flake (offering e.g. opentofu 1.8.7), whereas some of our development shells have used an instance from npins (offering opentofu 1.8.5, used in a dev shell's `tofu init`). - `launch/tf.nix` - `panel/env.nix` - `panel/default.nix` - `infra/machines/fedi201/fedipanel.nix` (1.8.7: flake) - `panel/nix/configuration.nix` - `panel/nix/package.nix` - `panel/default.nix` - `infra/machines/fedi201/fedipanel.nix` (1.8.7: flake) - `panel/nix/configuration.nix` - `panel/default.nix` - `infra/machines/fedi201/fedipanel.nix` (1.8.7: flake) - `launch/default.nix`: shell (1.8.5: npins) note that there have been various reasons for how this came about: - `flake.nix`: used as nixops wants flake outputs - `nixpkgs`: used as flake-parts' system isn't explicitly known in `infra/flake-part.nix` to instantiate an npins nixpkgs - `npins/sources.json`: used as @fricklerhandwerk used it and we opted to make a distinct shell for the panel - `nixpkgs`: taken from npins as consuming this from flake seems [more involved](https://github.com/fricklerhandwerk/flake-inputs/)    note that there have been multiple barriers toward potentially [replacing flakes](https://git.fediversity.eu/kiara/meta/compare/main...on-flakes) (tho at least they can [import](https://github.com/fricklerhandwerk/flake-inputs/) one another's): - outputs - [ ] nixops4 using this (#309) - ~~[ ] nixos-anywhere TF's `special_args` [only supporting flakes so far](https://github.com/nix-community/nixos-anywhere/issues/462)~~ - superseded by #307 - inputs - [ ] importing modules exposed this way from without flakes would need rework - [ ] instantiating nixpkgs from npins wants a `system`, whereas we haven't had this exposed in our flake parts - [x] npins [double downloading bug](https://github.com/andir/npins/issues/57)

Rows
Columns