Add Nix files and commit Cargo.lock

[pnmadelaine]

No description provided.

[W95Psp]

Thanks!
I have a few comments:

• Why only "x86_64-linux"? Things should work fine on other architectures.
• We should expose the Rust binaries provided by the crate (e.g. simple_https_{server,client})
• We should also run hax-driver.py extract-proverif

[franziskuskiefer]

When committing the log file you need to update the CI here to update dependencies.

[pnmadelaine]

@franziskuskiefer this would be a very weird CI workflow, where the lockfile is completely decorrelated from what is actually tested.
Best thing to do imo is, as @W95Psp suggested on Zulip, to use dependabot as a separate workflow to keep dependencies updated.

[franziskuskiefer]

I don't see anything weird.
In any case. This PR needs to go along with a CI here that tests the library without the lock file.
I don't see how dependabot helps with that. But if you have a workflow with that, feel free to propose it.

[pnmadelaine]

I don't see anything weird.

Having the lockfile completely ignored by CI, and thus the CI not giving information about the current build status of the repository is at the very least counter-intuitive.

In any case. This PR needs to go along with a CI here that tests the library without the lock file. I don't see how dependabot helps with that. But if you have a workflow with that, feel free to propose it.

The workflow we propose is to run tests with the locked dependencies, so as to ensure the same set of dependencies is used by developers, users and the CI, and to update them periodically with a separate workflow (dependabot, which is already configured on this repository).

[pnmadelaine]

I don't see how dependabot helps with that.

dependabot will automatically open PRs to update outdated dependencies

[franziskuskiefer]

Having the lockfile completely ignored by CI, and thus the CI not giving information about the current build status of the repository is at the very least counter-intuitive.

No one said that it should be ignored. But you must test both cases, using the lock file, and not using it.

so as to ensure the same set of dependencies is used by developers, users and the CI

This is not the case. Cargo doesn't use the lock file in many cases. That's also why we need to test with the toml, as that's the source of truth.

[W95Psp]

Thanks, LGTM!

Looks like there is a linting issue, somehow 👀
Can you rebase your PR with #119? I pushed a fix there

[pnmadelaine]

@W95Psp done!

Changes have been addressed

[pnmadelaine]

I was just thinking, we should discuss committing flake.lock.
If it is committed it needs to be updated regularly, otherwise the nix build will quickly fail and the lock file will become useless anyway.
@W95Psp what do you think?

[W95Psp]

I see no point in not commiting flake.lock, of we don't commit flake.lock, we should drop the nix expressions all together.
The nix job you added will check the nix expressions are up to date as code changes, that's all we need imo.
Locked flakes are especially useful to make sure we'll be able to build the project in the future.