Hacker News Reader

Comment by dbpokorny | Hacker News Reader

I haven't used it, but second hand I've heard that the Python version of this concept is "virtualenv".

Edit: I probably shouldn't be surprised to learn that second hand information I picked up six years ago at PyCon is out of date...

View on HN

Not quite. The Python equivalent is Pyenv: https://github.com/yyuu/pyenv

I'm a relatively experienced python developer and have never even installed pyenv.

Whereas with Ruby, I can't seem to get much working without it.

You can take a fresh install of MacOSX and do anything with Ruby. Only issue is you need to install some gems using sudo. Same thing with using system python. You don't need rbenv by any means. In fact our designer has no problem getting our rails site running and making styling edits.

Hard to say the same with installing Python 3 on MacOSX and getting virtualenv running, which in my experience hasn't been so easy.

How would you work on a project that uses 3.2, then another that uses the latest features from 3.5, without pyenv?

I seem to have all of Python 2.7, 3.2, 3.3, and 3.5 installed on my server just from APT. I happen to only use 2.7, but I certainly don't see what use I would have for some crazy tool to manage versions of Python for me... if the project needs Python exactly 3.2 for some specific reason I can just run python3.2 instead of python3.5 or python3.

If you work on multiple Django or Flask projects you'll quickly learn APT can start solving your problems but it won't be the best way to do it.

With virtualenv each project of mine has a requirements file (I use it even for Google App Engine development, having a distinct SDK per project) and runs Python from a different environment where the packages I install with pip do not interfere with any other environment. Without it an "apt-get upgrade" can end up breaking everything (to say nothing about not having the latest version packaged).

I have a tendency to install one of python 2.x and one of python 3.x and then use the --python flag to set the particular python I want my project to run against.

At that point it should work invisibly in the virtualenv.

Unlike ruby, point releases don't often make sweeping breaking changes so it is often enough to say 'this is python 3 code' or 'this is python 2 > 2.5' code, so the granularity of something like pyenv is mostly unnecessary, imo.

That's the way I worked at my last job with Python. I filed for brain fuckery bankruptcy after trying to get pyenv and pyenv virtualevnwrapper set up.

You can't say this is Python 3 code or Python 2 code. That's completely false. If someone used latest features from Python 3.5 that wouldn't work on 3.4.

Also, I haven't had any issues upgrading point releases in Ruby(since 2.0). Point releases do not make sweeping changes by any means. You maybe talking about the weird 1.8 to 1.9.3 thing.

The real equivalent in the Python world is pyenv. In fact, pyenv is based on rbenv. virtualenv itself lacks the ability to manage different Python versions.

And in node world it's nvm

Nodenv [1] would be the node equivalent.

[1]: https://github.com/OiNutter/nodenv

Not so. Virtualenv's spiritual Ruby equivalent is Bundler.

But technically no. Virtualenv is quite different, both in scope and approach. https://github.com/Deepwalker/pundler is more similar to bundler

Reply on news.ycombinator.com