A tool to create isolated Haskell environments, inspired by Python's virtualenv, for sandboxed development.
hsenv is a tool for creating isolated Haskell development environments, similar to Python's virtualenv. It solves dependency conflicts and version mismatches by sandboxing GHC, cabal, and installed packages on a per-project basis. This allows developers to work on multiple Haskell projects with different requirements simultaneously.
Haskell developers working on multiple projects or needing to test code with different GHC versions. It's particularly useful for library maintainers and contributors who must ensure builds are reproducible and isolated.
Developers choose hsenv because it's lightweight, integrates with standard Haskell tooling, and provides true environment isolation without complex wrappers. Unlike other tools, it supports multiple GHC versions and named environments, offering flexibility for advanced workflows.
Virtual Haskell Environment builder
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Creates a .hsenv/ directory that sandboxes GHC, cabal, and all packages, preventing conflicts with global or user environments as described in the basic usage.
Supports using different GHC versions than the system, including automatic downloading from remote repositories, demonstrated in the advanced usage with --ghc flag.
Allows creating multiple named environments within a single directory, enabling different configurations for the same project without recompilation, as shown with --name option.
Works with standard Haskell tools like ghc and cabal, and includes a simple Emacs mode for editor activation, integrating into existing workflows without heavy wrappers.
The README explicitly doubts it works on Windows except possibly with Cygwin, making it unsuitable for native Windows development without patches or workarounds.
FAQ states it cannot be used alongside tools like cabal-dev or capri due to similar wrapping mechanisms, forcing users to choose one ecosystem and potentially break existing setups.
Requires explicit activation via sourcing scripts and deactivation, lacking built-in automation for directory-based activation without custom shell hacks.
As per the FAQ, using hsenv inside another hsenv is not supported, which limits flexibility for advanced testing or layered dependency management.