Sam/neutron darwin

[hxrts]

this should now make it so we have a cosmos, ethereum, and solana node that can run locally with nix on macos

[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 enhances the local development environment by adding full support for running a Neutron node on macOS using Nix. My changes introduce custom Nix packages for neutrond and its libwasmvm dependency, specifically addressing macOS compatibility issues, and integrate these into the existing flake structure to provide a seamless experience for developers.

Highlights

• macOS Neutron Support: I've introduced a new Nix flake module (flakeModules/neutron-darwin.nix) and associated packages (packages/neutron-darwin.nix) to enable building and running the Neutron node (neutrond) locally on macOS. This addresses the challenge of libwasmvm compatibility on Darwin.
• Custom libwasmvm Build: I've added a custom Nix build for libwasmvm (version 2.1.5) specifically tailored for macOS, including necessary Darwin frameworks (Security, SystemConfiguration) and setting the MACOSX_DEPLOYMENT_TARGET.
• Darwin-Compatible neutrond: I've implemented a Nix build for neutrond (version 6.0.3) that links against the custom macOS-compatible libwasmvm. This includes CGO enablement, specific build flags, and install_name_tool usage to correctly resolve dynamic library paths on Darwin.
• Smart Neutron Wrapper: A neutron shell script wrapper has been added. This wrapper prioritizes the Nix-built neutrond with proper DYLD_LIBRARY_PATH settings for macOS, but also includes a fallback to a system-installed neutrond if the Nix version isn't found.
• Development Environment Integration: The new Neutron packages are now exposed in the development shell, and the shellHook has been updated to inform users about the availability of neutrond with macOS support.

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 is currently in preview and 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 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 adds Nix-based support for running a Neutron node on macOS (Darwin). I've provided a few suggestions to improve maintainability and remove redundancy, such as avoiding repeated package calls, referencing package versions dynamically, and simplifying wrapper scripts. I also noted some minor stylistic issues like an unused dependency.

[gemini-code-assist]

The expression pkgs.callPackage ./neutron-darwin.nix {} is evaluated three separate times. This is inefficient and violates the DRY (Don't Repeat Yourself) principle. It would be better to evaluate it once, store the result in a let binding, and then reference the attributes from that variable.

For example, you could introduce a let binding in the parent scope:

# In the `let` block of the `perSystem` module
neutronPkgs = pkgs.callPackage ./neutron-darwin.nix {};

# Then in the `packages` attribute set
...
# Neutron with Darwin support
neutron-darwin = neutronPkgs.neutron;
libwasmvm = neutronPkgs.libwasmvm;
neutrond = neutronPkgs.neutrond;
...

Since a direct suggestion is constrained to the changed lines, I'm providing this as a broader refactoring suggestion.

[gemini-code-assist]

The version "2.1.5" is hardcoded in this shell hook message. This version is also defined in packages/neutron-darwin.nix. If the package version is updated in the future, this message will become outdated and misleading. To avoid this, you should reference the version dynamically from the libwasmvm package derivation.

echo "Neutron: neutrond (with macOS support via libwasmvm ${if pkgs.stdenv.isDarwin then config.packages.libwasmvm.version else \"from cosmos-nix\"})"

[gemini-code-assist]

The fetchurl dependency is imported but not used in this file. It's good practice to remove unused dependencies to keep the code clean and avoid confusion.

[gemini-code-assist]

This export command is redundant. The neutrond derivation is already wrapped using wrapProgram in the postFixup phase (lines 113-116), which correctly sets DYLD_LIBRARY_PATH or LD_LIBRARY_PATH. The wrapper generated by wrapProgram will be executed when "${neutrond}/bin/neutrond" is called, so this manual export is unnecessary and can be removed to simplify the script.

exec "${neutrond}/bin/neutrond" "$@"