Sort of, but they necessarily approach the problem from different vectors.
An operating system design with a seamless, straightforward, easy-to-use mechanism for handling all potential dependency conflicts on a multi-purpose, multi-user system is a very hard problem. Any solution is likely to be complex and potentially confusing to users, such as debian alternatives or the modules environment system. Every language has its own library management system: cpan, pip, rubygems, leiningen, etc., and they all profit off the assumption that they are managing a single set of requirements and dependencies. Operating Systems do not have that luxury.
On the other hand from the user perspective, they may not even have root on a system and as such may not even be able to install libraries without contacting a system administrator. Maybe it's a shared hosting environment, maybe it's a research compute cluster, maybe there are SOX restrictions on developers, whatever. Virtual environments focus directly on giving the user/app what they need and isolating that user from everything else.
100 different users can use virtualenv to create 100 different, completely not-compatible python environments and they're all happy. How would an Operating System do that, without essentially duplicating what virtualenv already does? (Not saying that OS developers aren't going to try, which Zed Shaw will then ridicule, but that's another story). For sandboxing in general, at what point do you create the sandbox? Usually for each individual app and usedr you don't want to have to answer questions about whether you still want the C++ compiler available or whether a virtualized /etc/passwd is needed. Those are the sort of questions you have to answer when designing OS-level sandboxes.
>> How would an Operating System do that, without essentially duplicating what virtualenv already does?
This, I think, is backwards: virtualenv must do it already because the os doesn't. I concede that creating something now may be too late not to suffer the "15 competing standards" effect.
You can always install from source and pass --prefix and --exec-prefix options to ./configure. Virtualenv is not strictly necessary to run in an isolated environment.
And as for whether virtualenv should have been part of the OS... it already is in some cases, to the extent that any userland tool is part of the OS.
$ uname -o
GNU/Linux
$ which virtualenv
/usr/bin/virtualenv
Does it really matter whether it was the python developers who got there first?
An operating system design with a seamless, straightforward, easy-to-use mechanism for handling all potential dependency conflicts on a multi-purpose, multi-user system is a very hard problem. Any solution is likely to be complex and potentially confusing to users, such as debian alternatives or the modules environment system. Every language has its own library management system: cpan, pip, rubygems, leiningen, etc., and they all profit off the assumption that they are managing a single set of requirements and dependencies. Operating Systems do not have that luxury.
On the other hand from the user perspective, they may not even have root on a system and as such may not even be able to install libraries without contacting a system administrator. Maybe it's a shared hosting environment, maybe it's a research compute cluster, maybe there are SOX restrictions on developers, whatever. Virtual environments focus directly on giving the user/app what they need and isolating that user from everything else.
100 different users can use virtualenv to create 100 different, completely not-compatible python environments and they're all happy. How would an Operating System do that, without essentially duplicating what virtualenv already does? (Not saying that OS developers aren't going to try, which Zed Shaw will then ridicule, but that's another story). For sandboxing in general, at what point do you create the sandbox? Usually for each individual app and usedr you don't want to have to answer questions about whether you still want the C++ compiler available or whether a virtualized /etc/passwd is needed. Those are the sort of questions you have to answer when designing OS-level sandboxes.