Hacker News Reader

Comment by cutler | Hacker News Reader

As a Ruby and Python developer I often wonder why Ruby doesn't need a virtual env. What did Ruby get right that Python didn't?

View on HN

Not sure about ruby, but most of the languages I know about, C#, javascript, php, etc don't need virtualenv because they install packages in a project locally (and globally if required). so envs of one project do not clash with another.

while python install packages globally and only globally. so a virtualenv is needed to isolate different projects from one another

Last time I used python I just did

pip install -r requirements.txt -t libs

and added the folder to PYTHONPATH. I never bothered with virtualenv.

That is basically virtualenv though it won't work in as many cases. Not that there is anything wrong with it, but I don't see how it's any better.

PYTHONPATH is also global! so all projects will still be referring to the same set of libs. how does that change anything at all?

That's an optional environment variable, it is not set unless you set it. Meaning you could change it to anything, per process. Also you can change sys.path. Not an issue.

What do you mean "python install[s] globally and only globally"? That's not true. You can instruct pip to install to any place you want.

the thing is python cli has no concept of locally scoped libraries. you can install libs wherever you want, but all python.exe will refer to the same global location.

this is why you need to activate virtualenv every time you open a new command line, so that it can set ENV variables for the current session and force python to use the locally scoped folders.

While in C# et all. the compiler knows to check files locally. and you don't need to activate (or deactivate) environment at all.

You don't need a virtualenv. You can simply launch python with the PYTHONPATH environment variable (there are also other ways).

For development, the "install everything locally" that virtual env provides. This avoids conflicting, incompatible versions of packages being installed in a global or per-user location.

Python isn't at all the only language to suffer this problem. e.g. "DLL hell" and its variations like Haskell's "cabal hell". With Ruby, if its packages are installed with bundler, then these packages are installed locally in the project directory.

People use RVM or rbenv to manage Ruby versions. The virtualenv analogue is Bundler, which provides something like requirements.txt and causes gems to be installed locally instead of globally. https://bundler.io/

Everyone ends up using rbenv or rvm.

You don't need them to solve this problem, though. The basic facilities are baked into rubygems.

The basic facilities are baked into python tools too, you can direct installation of packages to arbitrary folders and then just add them to your PYTHONPATH.

But it's not as quick and clean as "python -m venv venv", so everyone uses that (and pyenv for different versions).

well, a lot of "system" utilities are implemented in Python and I'm not aware of many in Ruby (they must exist? I just checked to see what on my system depends on Ruby and it seems like the only things are a screenruler utility, some texlive packages I've never heard of and gnome-code-assistance, whatever that is). Pip installing random crap is a great way to completely break some Linux systems.

Running pip as root is a great way to self-compromise. Would you ever run npm as root...?

Absolutely... I usually do python setup.py bdist_rpm if I want to install some package systemwide. Not sure it's really any safer, but it sure feels safer...

Or a lot of other languages...

Reply on news.ycombinator.com