nix-shell is a tool unlike any other for working with project dependencies. However, so much more can be done!
A lot of this can already be accomplished with nix-shell, so a simple approach might be to fix the flaws in nix-shell and leave the rest of the effort for the community to figure out. That's very modular, but doesn't improve the situation much beyond the status quo. In fact, solutions like IDEs and docker-compose currently provide better solutions for some of the problems (but are stuck in local optima).
- Build dependencies
- Merge dependencies (buildEnv)
- Start services
- Run a user-provided command
- Stop services
- Standardize commands like update-dependencies, start language server
- Filter environment variables
- Should work on Mac
- Connect networks of services a la docker-compose
- Configure non-service non-package dependencies like state directories, online service accounts
- Replace services at runtime depending on developer needs (mock vs real vs hot-reload)
- Be forward compatible
- Provide a comprehensive expression that has all the dependencies for all possible was the project can be used by a developer (example: the hot reload code)
- External sets of tooling a la np-cabal, np-styx etc (better standard tooling for everyone)
- Integrate with IDEs
- Walk the dog
- Make the world a better place
CS has only two hard problems, naming things and clichés.
This thing/these things will need a good name. I would love to call it nix-env, but (because?) that's already taken. So we need to figure out a new name. This should be done after designing the primary tool/tools. Obligatory non-exhaustive list:
- nix environment
- nix compose
- nix net
- nix context
- nix project
- nix service
- nix your-name-here
- more than one command
Let's stick with nix foo for any proofs of concept.