A Nix-based tool for creating per-project developer environments with clean shells and minimal dependencies.
devshell is a Nix-based tool designed to create per-project developer environments, similar to virtualenv but for all programming languages. It provides isolated shells with only the necessary development dependencies, ensuring consistency and reducing setup time for new contributors or team members.
Developers and teams using Nix who need reproducible, project-specific development environments, especially in open-source projects or organizations with multiple codebases.
It offers a cleaner alternative to `pkgs.mkShell` by minimizing environment pollution, supports TOML configuration for ease of use, and integrates seamlessly with existing Nix workflows like direnv and flakes.
Per project developer environments
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Starts from a minimal derivation, avoiding the bloat of pkgs.stdenv, which drastically reduces unnecessary environment variables—shown in the direnv export comparison from dozens to just a few.
Works out of the box with nix-shell, direnv, and Nix flakes, ensuring compatibility with existing Nix workflows and tools without modification.
Allows non-Nix experts to define environments using simple TOML files, covering 80% of use-cases while falling back to Nix for advanced needs, lowering the learning curve.
Automatically displays a welcome message with categorized available commands when entering the shell, accelerating new contributor ramp-up time by providing immediate context.
Marked as unstable in the README, meaning APIs may change frequently, which can disrupt long-term projects and require constant updates.
Primarily supports bash, with other shells only partially available via direnv—acknowledged in the TODO list as a missing feature for broader adoption.
The TODO list highlights gaps in documentation for all use-cases and lacks comprehensive integration tests, making it harder to troubleshoot or verify setups.
Lazy loading of dependencies is a planned feature but not yet implemented, leading to potentially larger closures and slower initial loads in some scenarios.