Refactor Nix shell into Nix flake

inex commented

2023-09-30 21:18:58 +03:00

Owner

Moving to flake will give us a unified environment across production installation, development and CI instances. This will also allow us to upgrade the system without the fear of breaking the API due to breaking changes in dependencies.

The work has began on the flake branch, and further testing is needed.

Moving to flake will give us a unified environment across production installation, development and CI instances. This will also allow us to upgrade the system without the fear of breaking the API due to breaking changes in dependencies. The work has began on the `flake` branch, and further testing is needed.

inex added the

Refactor

label 2023-09-30 21:18:58 +03:00

alexoundos was assigned by inex

2023-09-30 21:18:58 +03:00

inex added this to the SelfPrivacy service packaging format project 2023-10-05 17:49:55 +03:00

alexoundos commented

2023-10-18 14:32:08 +03:00

Collaborator

Branch with the flake.nix:
https://git.selfprivacy.org/SelfPrivacy/selfprivacy-rest-api/commits/branch/flake

Branch with the flake.nix: https://git.selfprivacy.org/SelfPrivacy/selfprivacy-rest-api/commits/branch/flake

alexoundos commented

2023-10-20 13:21:57 +03:00

Collaborator

We need compatibility of this API application with multiple NixOS configurations (each NixOS configuration provides nixpkgs input, which is passed to API project as well). So we need to build and test API application against several NixOS configurations (several commits).

When we base this API project on specific NixOS configuration commits, it seems we need to have several flake lock files:

[current API commit] <- [selfprivacy-nixos-config.git?rev=11567d4] <- [nixpkgs...]
nixos-11567d4-flake.lock
[current API commit] <- [selfprivacy-nixos-config.git?rev=2d7680d] <- [nixpkgs...]
nixos-2d7680d-flake.lock
[current API commit] <- [selfprivacy-nixos-config.git?rev=f11d8cc] <- [nixpkgs...]
nixos-f11d8cc-flake.lock

Hence, continuous integration system will be able to test all required combinations of API & NixOS configuration, after building like this:

nix build --no-write-lock-file --reference-lock-file nixos-11567d4-flake.lock
nix build --no-write-lock-file --reference-lock-file nixos-2d7680d-flake.lock
nix build --no-write-lock-file --reference-lock-file nixos-f11d8cc-flake.lock

Other naming ideas instead of nixos-11567d4-flake.lock:

based-on-nixos-11567d4-flake.lock
for-nixos-11567d4-flake.lock
for-config-2023-10-20-11567d4-flake.lock

No longer compatible flake lock files will be removed in the relevant commits. New will be added. For each commit after CI gets its job done successfully with each flake lock combination, CI marks commit as good, hence we're sure the combination works.

Or do we need to build the API application against different SelfPrivacy NixOS configurations at all?

@inex, what do you think?

We need compatibility of this API application with multiple NixOS configurations (each NixOS configuration provides nixpkgs input, which is passed to API project as well). So we need to build and test API application against several NixOS configurations (several commits). When we base this API project on specific NixOS configuration commits, it seems we need to have several flake lock files: * `[current API commit]` <- `[selfprivacy-nixos-config.git?rev=11567d4]` <- `[nixpkgs...]` nixos-11567d4-flake.lock * `[current API commit]` <- `[selfprivacy-nixos-config.git?rev=2d7680d]` <- `[nixpkgs...]` nixos-2d7680d-flake.lock * `[current API commit]` <- `[selfprivacy-nixos-config.git?rev=f11d8cc]` <- `[nixpkgs...]` nixos-f11d8cc-flake.lock Hence, continuous integration system will be able to test all required combinations of API & NixOS configuration, after building like this: * `nix build --no-write-lock-file --reference-lock-file nixos-11567d4-flake.lock` * `nix build --no-write-lock-file --reference-lock-file nixos-2d7680d-flake.lock` * `nix build --no-write-lock-file --reference-lock-file nixos-f11d8cc-flake.lock` Other naming ideas instead of `nixos-11567d4-flake.lock`: * `based-on-nixos-11567d4-flake.lock` * `for-nixos-11567d4-flake.lock` * `for-config-2023-10-20-11567d4-flake.lock` No longer compatible flake lock files will be removed in the relevant commits. New will be added. For each commit after CI gets its job done successfully with each flake lock combination, CI marks commit as good, hence we're sure the combination works. --- Or do we need to build the API application against different SelfPrivacy NixOS configurations at all? --- @inex, what do you think?

inex commented

2023-10-20 16:20:36 +03:00

Poster

Owner

sp-nixos-11567d4-flake.lock would be a good name, I think.

Or do we need to build the API application against different SelfPrivacy NixOS configurations at all?

It is a NixOS configuration that declares a specific API version, so if needed we can in theory generate a list of revisions that depend on a specific API version.

`sp-nixos-11567d4-flake.lock` would be a good name, I think. > Or do we need to build the API application against different SelfPrivacy NixOS configurations at all? It is a NixOS configuration that declares a specific API version, so if needed we can in theory generate a list of revisions that depend on a specific API version.

alexoundos closed this issue

2023-11-01 16:56:49 +02:00

alexoundos reopened this issue

2023-11-01 16:56:58 +02:00

inex closed this issue

2024-02-01 17:59:00 +02:00

inex commented

2024-02-01 17:59:30 +02:00

Poster

Owner

Fixed by #85

Refactor Nix shell into Nix flake #63