Naersk is a Nix library that automates building Rust projects by parsing `Cargo.lock` and creating Nix derivations for dependencies and the final binary. It leverages Nix's sandboxing and caching to achieve reproducible and incremental builds. The library exposes a single entry point, `buildPackage`, which accepts a source directory (or attribute set) and returns a derivation. Internally, it implements a two-phase build: first compiling all dependencies into a cached derivation, then compiling the user's crate with those pre-built dependencies. This architecture optimizes rebuild times when only the application code changes. Key capabilities include support for git dependencies, workspace crates, custom `rustc`/`cargo` toolchains, cross-compilation (via `CARGO_BUILD_TARGET`), and automatic crate-specific overrides (e.g., adding `openssl` and `pkg-config` for the `openssl-sys` crate). The codebase is implemented entirely in pure Nix, showcasing advanced Nix patterns like recursive toml serialization, generic closure traversal, and dynamic source stub generation. The project is actively maintained, has a comprehensive test suite (fast and slow), and is widely used in the Nix ecosystem.
This repository provides the `honggfuzz` Rust crate, which integrates Google's Honggfuzz fuzzer with Rust. It offers a library with a `fuzz` function and `fuzz!` macro for defining fuzz targets, and two cargo subcommands (`cargo hfuzz` and `cargo honggfuzz`) for building with fuzzing instrumentation and running the fuzzer. The crate handles persistent fuzzing, conditional compilation via `cfg(fuzzing)`, and supports both raw byte slices and structured inputs via the `arbitrary` crate. The build script compiles the Honggfuzz C library from a submodule and links it statically. The codebase is well-structured, with clear separation between the library, CLI tools, and build infrastructure, and demonstrates thoughtful engineering for a security testing tool.
Deps.rs is a production web service that analyzes Rust project dependencies to detect outdated or insecure versions. It fetches Cargo.toml manifests from source repositories (GitHub, GitLab, Bitbucket, SourceHut, Codeberg, Gitea) or crates.io, crawls workspace members and internal dependencies, then compares declared version requirements against the latest crates.io releases while checking every release against the RustSec Advisory Database. Results are rendered as an HTML page with per-dependency status tables and as configurable SVG badges (flat, flat-square, for-the-badge) for README integration, plus a shields.io-compatible JSON endpoint. Built as a single-binary monolithic web server using Actix-web, Tokio, and Reqwest, the application maintains its own cached crates.io Git index with smart recovery strategies (slotmap expansion, full reclone) and uses an LRU cache with TTL for query responses. The codebase follows modern Rust idioms (async/await, edition 2024, comprehensive testing) and is well-organized into separable modules: an engine with finite-state machines for manifest crawling and dependency analysis, a badge rendering library (standalone workspace member), and a parser for Cargo.toml with support for target-specific and renamed dependencies.
ggez is a lightweight, cross-platform 2D game framework for Rust, inspired by LÖVE. It provides a comprehensive set of subsystems for graphics, audio, input, filesystem, and timer management, all accessible through a central `Context` object. The framework abstracts over `winit` for windowing and events, `wgpu` for GPU rendering, `rodio` for audio playback, and `gilrs` for gamepad support. The architecture is modular, using sub-contexts (e.g., `GraphicsContext`, `AudioContext`) that can be individually accessed via `Has`/`HasMut` traits, allowing for custom context composition. The graphics pipeline supports 2D and optional 3D rendering (behind a feature flag) with shaders, meshes, images, instanced drawing, and text rendering via `glyph_brush`. The filesystem uses a virtual filesystem (VFS) layer with physical directories and zip archives, and configuration is handled via TOML serialization. Key entry points include `ContextBuilder` for initialization, `EventHandler` trait for the game loop (with `update`, `draw`, and input callbacks), and the `event::run()` function to start the application. Data flows are event-driven: user input is collected by `winit` and forwarded to the event handler, while rendering commands are batched and submitted to the GPU each frame. The framework also includes built-in coroutines for asynchronous tasks without futures. The repository contains over 40 examples demonstrating all major features, from simple drawing to complex 3D scenes and shader effects. ggez is actively maintained with a stable API, though some parts (e.g., 3D support, coroutine implementation) are less mature. The codebase demonstrates good engineering practices: builder patterns, resource caching, buffer sub-allocation, and a clear separation of concerns. It is suitable for hobby game development, educational projects, and rapid prototyping. The heavy reliance on evolving crates like `wgpu` and `winit` introduces some technical drift, but the framework keeps pace with updates.