Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add flake.nix to SRI #1334

Closed
Shourya742 opened this issue Jan 7, 2025 · 5 comments
Closed

Add flake.nix to SRI #1334

Shourya742 opened this issue Jan 7, 2025 · 5 comments

Comments

@Shourya742
Copy link
Contributor

Add a flake.nix file to the repository to standardize and simplify the development environment setup using Nix flakes. This will ensure consistent dependency management, reproducible builds, and alignment across different systems and contributors. By introducing flake.nix, we can provide a unified configuration for tools, Rust toolchains, and any project-specific dependencies, streamlining the onboarding process and minimizing environment-related issues. The flake should define the required Rust version (aligned with rust-toolchain.toml) and any additional tools or components needed for development, testing, and CI pipelines.

@plebhash
Copy link
Collaborator

plebhash commented Jan 8, 2025

as a nix user, I find this idea quite interesting, but I feel this requires a bit more brainstorming


first and foremost, we cannot force any SRI contributors to start using nix... it has a steep learning curve and it can actually slow down productivity for those who are not used to it

therefore, it's very important to have the following restrictions in mind:

  • any kind of critical workflow must remain as unopinionated as possible, only having nix as a convenient alternative for the contributors that decide to adopt it
  • maintenance of *.nix files must be a burden for the nix-using contributors, not otherwise
  • the trade-offs for maintenance must be justified... otherwise, we might find ourselves spending a lot of time on something just "because it's cool" without any real productivity benefits

second, the original proposal feels very broad and generic, and a few questions come to mind:

  • what are the concrete problems that we're trying to tackle?
  • why a flake.nix, and not a simple shell.nix?

again, as a nix user I like the idea and I'm not opposing it

but overall if we were to go in this direction, it's important to have a solid rationale!

@plebhash
Copy link
Collaborator

plebhash commented Jan 8, 2025

@Georges760 I see you liked this issue, and you also mentioned you use a shell.nix for SRI development on your local setup

can you share your shell.nix and provide more insights on how nix is improving your workflow?

why are you using it? which problems are you solving?

@Georges760
Copy link

  • de-offs

Of course, here is my shell.nix :

{ pkgs ? import <nixpkgs> {} }:
  let
    overrides = (builtins.fromTOML (builtins.readFile ./rust-toolchain.toml));
    libPath = with pkgs; lib.makeLibraryPath [
      # load external libraries that you need in your rust project here
    ];
in
  pkgs.mkShell rec {
    buildInputs = with pkgs; [
      clang
      cmake
      openssl
      # Replace llvmPackages with llvmPackages_X, where X is the latest LLVM version (at the time of writing, 16)
      llvmPackages.bintools
      pkg-config
      rustup
    ];
    RUSTC_VERSION = overrides.toolchain.channel;
    # https://github.com/rust-lang/rust-bindgen#environment-variables
    LIBCLANG_PATH = pkgs.lib.makeLibraryPath [ pkgs.llvmPackages_latest.libclang.lib ];
    shellHook = ''
      export PATH=$PATH:''${CARGO_HOME:-~/.cargo}/bin
      export PATH=$PATH:''${RUSTUP_HOME:-~/.rustup}/toolchains/$RUSTC_VERSION-x86_64-unknown-linux-gnu/bin/
      '';
    # Add precompiled library to rustc search path
    RUSTFLAGS = (builtins.map (a: ''-L ${a}/lib'') [
      # add libraries here (e.g. pkgs.libvmi)
    ]);
    PKG_CONFIG_PATH = "${pkgs.openssl.dev}/lib/pkgconfig";
    LD_LIBRARY_PATH = libPath;
    # Add glibc, clang, glib, and other headers to bindgen search path
    BINDGEN_EXTRA_CLANG_ARGS =
    # Includes normal include path
    (builtins.map (a: ''-I"${a}/include"'') [
      # add dev libraries here (e.g. pkgs.libvmi.dev)
      pkgs.glibc.dev
    ])
    # Includes with special directory paths
    ++ [
      ''-I"${pkgs.llvmPackages_latest.libclang.lib}/lib/clang/${pkgs.llvmPackages_latest.libclang.version}/include"''
      ''-I"${pkgs.glib.dev}/include/glib-2.0"''
      ''-I${pkgs.glib.out}/lib/glib-2.0/include/''
    ];
  }

It is a little bit messy, as I am on NixOS for few month only, and still learning it.

@jbesraa
Copy link
Contributor

jbesraa commented Jan 9, 2025

may I ask why are you using nix? what kind of problems it solved for you while working on SRI?

@Georges760
Copy link

may I ask why are you using nix? what kind of problems it solved for you while working on SRI?

I was bored to lose (again) my whole ubuntu system at a "dist-upgrade", so wanted to test NixOS. I kind of like it now, begining was difficult (like Rust) but once everything is running, it is very convenient to maintain.

@stratum-mining stratum-mining locked and limited conversation to collaborators Jan 10, 2025
@plebhash plebhash converted this issue into discussion #1344 Jan 10, 2025

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants