updates nix flake to sp1 5.0 and uses the valence sp1 derivation + crate2nix

[hxrts]

No description provided.

[gemini-code-assist]

Summary of Changes

Hello @hxrts, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly modernizes the project's Nix flake setup by upgrading the SP1 toolchain integration to version 5.0 via sp1-nix and adopting crate2nix for Rust dependency management. These changes aim to improve build reproducibility, simplify development environments, and update core Valence coprocessor dependencies, streamlining the overall development and deployment experience.

Highlights

• Nix Flake Modernization: The Nix flake configuration has undergone a significant overhaul, migrating from inlined derivations and manual toolchain management to leveraging external flake inputs like crate2nix and sp1-nix. This simplifies dependency management and ensures consistent build environments for Rust and SP1 components.
• SP1 Integration Update: The project now utilizes the sp1-nix flake for managing the SP1 toolchain, replacing a previously inlined and manually managed setup. This aligns with the PR title's mention of 'sp1 5.0' and 'valence sp1 derivation', indicating an upgrade and standardized approach to SP1 development.
• Rust Dependency Management with crate2nix: Integration of crate2nix automates the generation of Nix derivations for Rust dependencies, as evidenced by the new Cargo.nix file. This streamlines the Rust build process within the Nix ecosystem and ensures reproducible builds.
• Valence Coprocessor Updates: The valence-coprocessor and valence-coprocessor-wasm dependencies have been updated from 0.3.4 to 0.3.7 across Cargo.toml and Cargo.lock, reflecting an upgrade to the core Valence components.
• Refactored Build and Deployment Scripts: Several utility scripts for building, deploying, proving, and retrieving data have been renamed and refactored (build-wasm to build-app, deploy-to-service to deploy-app, valence-prove to prove-app and derive-vk, valence-storage to get-proof). This improves clarity and modularity of the development workflow.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request is a significant improvement, refactoring the Nix environment to use sp1-nix and crate2nix. This simplifies the setup, enhances maintainability, and clarifies the build and deployment scripts. I've left a few comments, mainly to correct a potentially problematic MACOS_DEPLOYMENT_TARGET version and improve the reproducibility of the Nix flake. Overall, great work on this refactor!

[gemini-code-assist]

The MACOS_DEPLOYMENT_TARGET is set to "10.03", which corresponds to macOS Panther (2003). This is very likely a typo and could lead to build failures or unexpected behavior on modern macOS systems. Please update this to a more recent version, such as 10.13 (High Sierra) or newer, depending on your minimum supported version.

A similar issue is present in the circuit-shell definition on lines 1191-1193.

              name = "MACOS_DEPLOYMENT_TARGET";
              value = "10.13";

[gemini-code-assist]

Similar to the wasm-shell, the MACOS_DEPLOYMENT_TARGET here is set to the very old version "10.03". This should be updated to a more recent macOS version to ensure compatibility and prevent build issues.

              name = "MACOS_DEPLOYMENT_TARGET";
              value = "10.13";

[gemini-code-assist]

The nixpkgs.url is set to nixpkgs/nixos-24.11. This is not a standard Nixpkgs branch and may not be stable or even exist in the future, which could break the flake. For better reproducibility and maintainability, it's recommended to pin nixpkgs to a specific commit hash. Using the revision from the flake.lock file is a good practice.

For example, based on the current flake.lock, you could use:
github:NixOS/nixpkgs/f09dede81861f3a83f7f06641ead34f02f37597f

    nixpkgs.url = "github:NixOS/nixpkgs/f09dede81861f3a83f7f06641ead34f02f37597f";