Add Nix flake

[aidenfoxivey]

@praveksharma @SWilson4 As I mentioned earlier, I wrote a little nix flake that should be able to run the environment without anything other than Nix installed on the machine - in addition to being declarative.

I'm happy to add or remove packages to the flake - I mostly followed the requirements for the QuickStart, but potentially missed something.

[baentsch]

Thanks for the proposal @aidenfoxivey ! Quick initial question (not knowing anything about nix): Does this have to reside in the top level project directory?

[aidenfoxivey]

Hi @baentsch!

In every project I've worked on, flake.nix and flake.lock do reside in the top level. That said, I was curious about the question, so I looked it up.

According to this reference (https://nixos.wiki/wiki/Flakes), flake.nix does have to be in the top-level.

My main goal with this is to have a declarative way to build liboqs to aid debugging and avoid having to use containers.

[SWilson4]

Thanks for the submission @aidenfoxivey!

I personally don't know anything about Nix, but I think two non–Nix-related issues would need to be resolved before this lands:

1. The flake should be tested in CI somehow.
2. There should be some sort of maintenance commitment to ensure the flake stays up to date—would you be willing to take this on?

[aidenfoxivey]

1. The flake should be tested in CI somehow.
   Sounds good! I'll write up a little testing setup sometime this week.

2. There should be some sort of maintenance commitment to ensure the flake stays up to date—would you be willing to take this on?
   Absolutely! I'm happy to be the designated flake maintainer.

[praveksharma]

The flake itself looks good to me, thank you @aidenfoxivey!

Could you also update the quickstart section of README.md to include instruction on how to use the flake?

Do you know if there's some way of parameterising the flake to spin up different dev envs, say with clang instead of gcc?

[aidenfoxivey]

Could you also update the quickstart section of README.md to include instruction on how to use the flake?

I'll remove the instructions from the flake and put them in the quickstart along with other information.

Do you know if there's some way of parameterising the flake to spin up different dev envs, say with clang instead of gcc?

I'll take a look!

[aidenfoxivey]

I think it's maybe better to version the flake starting from 0.0.1, but alternative perspectives are certainly appreciated.

[aidenfoxivey]

Not sure what I did to boggle the code formatting lol. Maybe something in how I did the README was an issue?

[aidenfoxivey]

@baentsch I'll look into generating it by default

[aidenfoxivey]

Turns out the version tag is completely unnecessary, since it can be referred to by its git hash anyways. I'll wait for additional comments and then clean up the git history once I've sorted out any requests.

[cothan]

LTGM! Thanks for the contribution. Please make sure the all the tests are passed before you merge.

[praveksharma]

This looks good, thank for you working on this @aidenfoxivey!

[baentsch]

LTGM! Thanks for the contribution. Please make sure the all the tests are passed before you merge.

Hmm -- this statement made me curious: What tests are there (to be) passed? I didn't find any (just searching for changes to .github/workflows). Wouldn't that/having such be prudent, @cothan @praveksharma ?

[cothan]

Hi @baentsch , I approve the PR while there are 6 tests (unrelated to the PR) are still running, since this PR doesn't add anything to Github flow, thus I expect them all to pass, and they did (I didn't aware at the time that each PR needs 2 approval). So I comment to make sure this PR will be merged in a green state.

[praveksharma]

I agree that having testing for the flake would be desirable @baentsch but I'm also uncertain what is the best way to go about it. I believe the current build targets are limited in that they don't allow the user to pass CMake options via the nix CLI; is that correct @aidenfoxivey?

Since the project doesn't plan on moving away from CMake, at this stage it might make more sense to focus on developer quality of life improvement via nix develop. This would be easy to test via a weekly CI job -- on a ubuntu:latest image with just nix that must pass some cmake build tests.

Alternatively, if there is some way of transparently exposing CMake options to nix that would also be suitable. Instead of a maintainer having to ensure compatibility with CONFIGURE.md that would be handled natively by nix.

[aidenfoxivey]

@praveksharma Just to be clear, you want changes on the README, right?

[praveksharma]

@praveksharma Just to be clear, you want changes on the README, right?

Yes, listing the relevant nix alternatives to the apt commands under Quick Start > Linux and Mac > 1. Install dependencies is what I had in mind.

[baentsch]

As part of my year-end review of stalled things, can I ask what the idea is with this PR:

• Add CI testing as per @SWilson4 's suggestion?
• Add a small(er) README section as per @praveksharma 's suggestion (also addressing my concerns)
• Drop PR without merge

Which of these options would you like to pursue, @aidenfoxivey ? One, all, none, something else?

[aidenfoxivey]

As part of my year-end review of stalled things, can I ask what the idea is with this PR:

• Add CI testing as per @SWilson4 's suggestion?
• Add a small(er) README section as per @praveksharma 's suggestion (also addressing my concerns)
• Drop PR without merge

Which of these options would you like to pursue, @aidenfoxivey ? One, all, none, something else?

Ah whoops! I've got to admit liboqs slipped by mind a little bit during the latter half of the term. I'm going to sort out the README section tonight.

Thinking about testing, I think I wrote a solution but never pushed it.

I'll look to wrap this up in the next few days.

[aidenfoxivey]

So I think there are a few things to think about:

• is the Nix flake formatted? (this doesn't seem that important to me)
• is it valid nix?
• does the build it produces work?

Are all of these in scope for what tests should do?

[dstebila]

So I think there are a few things to think about:

* is the Nix flake formatted? (this doesn't seem _that_ important to me)

* is it valid nix?

* does the build it produces work?

Are all of these in scope for what tests should do?

@baentsch Is this what you had in mind when it came to testing?

[baentsch]

So I think there are a few things to think about:

* is the Nix flake formatted? (this doesn't seem _that_ important to me)

* is it valid nix?

* does the build it produces work?

Are all of these in scope for what tests should do?

@baentsch Is this what you had in mind when it came to testing?

It's a start - with item 3 being the most relevant imo.

[aidenfoxivey]

Okay, that functionality should be added now. Had to implement a small fix to prevent it from trying to rewrite a copy of the CMake file internally.

[dstebila]

Hi @aidenfoxivey, do you think you will be able to address the point above from security scanner? Is there anything else to be done before merging this?

[aidenfoxivey]

Hi @aidenfoxivey, do you think you will be able to address the point above from security scanner? Is there anything else to be done before merging this?

I've just pinned them to the latest version I could find. I'm running it locally on my Mac to give it a check.

[aidenfoxivey]

Woohoo!

[Nix Flake Check/tests]   ✅  Success - Main ${GITHUB_ACTION_PATH}/install-nix.sh
[Nix Flake Check/tests]   ⚙  ::set-env:: TMPDIR=/tmp
[Nix Flake Check/tests]   ⚙  ::add-path:: /nix/var/nix/profiles/default/bin
[Nix Flake Check/tests]   ⚙  ::add-path:: /root/.nix-profile/bin
[Nix Flake Check/tests]   ✅  Success - Main cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72
[Nix Flake Check/tests]   ⚙  ::set-env:: TMPDIR=/tmp
[Nix Flake Check/tests]   ⚙  ::add-path:: /nix/var/nix/profiles/default/bin
[Nix Flake Check/tests]   ⚙  ::add-path:: /root/.nix-profile/bin
[Nix Flake Check/tests] ⭐ Run Main nix build
[Nix Flake Check/tests]   🐳  docker exec cmd=[bash -e /var/run/act/workflow/2] user= workdir=
warning: Git tree '/Users/aidenfoxivey/src/liboqs' is dirty
[Nix Flake Check/tests]   ✅  Success - Main nix build
[Nix Flake Check/tests] ⭐ Run Main nix flake check
[Nix Flake Check/tests]   🐳  docker exec cmd=[bash -e /var/run/act/workflow/3] user= workdir=
warning: Git tree '/Users/aidenfoxivey/src/liboqs' is dirty
warning: The check omitted these incompatible systems: aarch64-darwin, x86_64-darwin, x86_64-linux
| Use '--all-systems' to check all.
[Nix Flake Check/tests]   ✅  Success - Main nix flake check
[Nix Flake Check/tests] ⭐ Run Post cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72
[Nix Flake Check/tests]   🐳  docker cp src=/Users/aidenfoxivey/.cache/act/cachix-install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72/ dst=/var/run/act/actions/cachix-install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72/
[Nix Flake Check/tests]   ✅  Success - Post cachix/install-nix-action@08dcb3a5e62fa31e2da3d490afc4176ef55ecd72
[Nix Flake Check/tests] ⭐ Run Complete job
[Nix Flake Check/tests] Cleaning up container for job tests
[Nix Flake Check/tests]   ✅  Success - Complete job
[Nix Flake Check/tests] 🏁  Job succeeded

[dstebila]

Thanks @aidenfoxivey!

@baentsch you've got a review requesting changes; does this clear your concerns? If so then please clear that in your review and then we can merge.

Dismissal requested. Still thinking testing would be appropriate, though.

[baentsch]

Thanks @aidenfoxivey!

@baentsch you've got a review requesting changes; does this clear your concerns? If so then please clear that in your review and then we can merge.

Not really -- but this is not worth fussing over.

[aidenfoxivey]

Should be moved into basic.yml now. That's the correct location right?

[aidenfoxivey]

I suspect that basic.yml isn't running for me due to not having committer access to open-quantum-safe. This is from my local fork running it. I'm thinking that perhaps the container I've chosen doesn't have sudo. This could prove an issue. I just used the default Ubuntu image beforehand - would that be fine to use instead?

@baentsch I'm happy to make changes in this PR or a follow up to make this more robust. I apologize for the delays in the middle of this.

(I'll be back at this after 5pm EST today to review comments and/or fix up the CI issues.)

[SWilson4]

I suspect that basic.yml isn't running for me due to not having committer access to open-quantum-safe. This is from my local fork running it. I'm thinking that perhaps the container I've chosen doesn't have sudo. This could prove an issue. I just used the default Ubuntu image beforehand - would that be fine to use instead?

I don't believe we install sudo in our containers—everything in CI runs as root anyhow. If the ubuntu-latest runner has the necessary dependencies to build the flake, that's fine (even preferable—it saves the time of downloading our image).

Looks like you'll have to rebase to get CI to run.

[aidenfoxivey]

Seems the Nix tests are working - happy to squash and force push when it's all passed.

[SWilson4]

LGTM, thanks @aidenfoxivey!