Hacker News Reader

Comment by Spiritus | Hacker News Reader

> [...] from time to time I need to write a script or use a popular python library like pygments and I used to hate having to do anything with python because of how difficult it seemed to install anything

Not sure I understand why you're having so much trouble. It's literally two commands:

    $ python3 -m venv venv  # Create virtualenv
    $ ./venv/bin/pip install pygments

However! One unfortunate thing with this is that `python3 -m venv` doesn't include the 'wheel' package in the virtualenv out-of-the-box. So it's often a good idea to install/upgrade pip, setuptools and wheel after creating the virtualenv:

    $ ./venv/bin/pip install -U pip setuptools wheel

View on HN

Virtual envs never made sense to me. I never understood what made Python so special that it needed these.

I never got where the virtual env is, what it does and why I need it.

Why can't I just `pip3 install xxx` and be done with it?

Python dependency management is a nightmare, and it seems like it always will be due to the insane number of so called "easy" solutions.

Python is not special in this case. Virtualenv is pretty much equivalent to:

- bundle --path env_directory

- gopath

- any other language's vendoring solution

In Ruby for example you can do "gem install foo" or add foo to Gemfile and use bundler. Those work similar to "pip install foo" or adding foo to pyproject and using poetry.

It was worse and complicated, but for years now it seems like complaining about venv is closer to a meme, since people go away and do pretty much the same thing in other languages. (Or don't have that option in something like C)

I don't know about Ruby, but it's nothing like Gopath or node_modules, nor Yarn PnP for what it's worth. Virtualenv still need to be created per project and must be "activated".

The fact that they're a somewhat hidden stateful context is still complicated and confusing.

The fact is when I retrieve a Python project, I still have no idea what command I should run to install the dependencies and setup everything. With Go modules it's just `go get`, and with JS projects it's just `npm install` or `yarn install`

The concept is the same. I'm not saying the implementation is identical. And I meant gopath before modules - where you have to explicitly define your environment.

"Not sure I understands why you're having so much trouble" ... proceeds to explain a procedure that involves understanding various moving parts, including virtualenvs, pip, setuptools, wheel, etc...

Even if I'm not gonna get deep into python, I like to feel like I understand what's going on. With python it just involves a lot more effort than with other ecosystems, even if you think that these things are easy to learn.

Compare with ruby: `gem install the-gem`. Done. No "virtual envs", no plethora of similar but different tools to do slightly the same thing / whatever, no preconditions, no step by step procedures. Simplicity is important!

My experience of Ruby, which is admittedly a few years old, is that people did use multiple Ruby environments through e.g rbenv to manage different sets of gem versions, which is what "virtual envs" are the equivalent of.

Now, I do agree the Python tooling situation is kind of a mess, but there you can still do:

"pip install the-package"

And you're just as good, all the other tools are when you're trying to do stuff harder like:

- Maintain multiple development environments - Publish new packages - Build binary packages - Handle Windows

I think on Ruby you need tools beyond "gem install" to do those as well. The point is how we achieve simplicity while keeping the ability to do those things.

You can just do 'pip install the-package' in python if you aren't using a virtual environment.

Ruby does have the equivalent of virtual environments, using RVM or rbenv (similar but different tools), to solve the same problems as in Python.

Reply on news.ycombinator.com