Hacker News Reader

So apart from having separate disk+network namespace, how is this different from a virtualenv? I feel like configurable sockets and paths should provide everything this can, but with less overhead.

View on HN

Less system resource overhead, more human overhead. VirtualEnvs can bleed over if they're not configured properly or if you forget to deactivate. They're harder to fully encapsulate and carry around (have to initiate with a special flag or there's a bunch of manual find+replace when changing paths). They sometimes end up with system dependencies (though `--no-site-packages` has been the default for a long time now).

This would be a shortcut that bypasses the need for venvs entirely. I'm not sure I would use it, but that's the difference I see.

There are a couple of tools to automatically manage virtualenv activation/deactivation, like autoenv[0] & detect_virtualenv[1];

[0]: https://github.com/kennethreitz/autoenv [1]: https://github.com/dgholz/detect_virtualenv

If I understand correctly, the container you develop in can also run a different operating system in a completely separate environment.

Reply on news.ycombinator.com