those are all means to the same end.

venv == virtualenv

virtualenvwrapper is ancient not rly used anymore

pyenv is a third party tool that makes some of this easier, notably around creating more than just a virtual env in that you also choose the Python version.

Python is not hard to deal with in this regard I think people are just uninformed.

Are you kidding me? The horrendous way Python does dependency management and virtual environments, and the fractured ecosystem around those, is one of it biggest pain points, often covered by core CPython developers and prominent Python third party developers, hardly "misinformed" people.

https://xkcd.com/1987/

That comic is very old. In the days of 2.x it was a little harrier but nothing like people make it out to be.

The literal only thing you need to understand is “sys.path”. If you inspect this in a shell you will know what you’re up against. Python is all literally just directories. It’s so easy and yet people get so bent out of shape over it.

Create a venv, activate it, and use pip as normal. If you ever run into issues, look at sys.path. That’s it.

>That comic is very old.

And few things have changed since then.

I’m gonna have to disagree with ya there bud. Never been easier to be a Python developer.

Which is irrelevant. We're talking about the dependencies/packaging/virtual environments situation, not whether "it's easy to be a Python developer" in general.

And you can disagree all you want, but it's simply wrong that Python's packaging/venv ecosystem is "just fine".

There are options to do things other ways, but most of the time I just use venvs and pip for everything.

Is it because people have to use venvs that people complain about it?

I’ll admit being able to install via an OS package manager, vs pip, vs anaconda etc etc can be confusing, but is any of that really Python (the language)’s fault?

how about:

pip install

pip install -u

sudo pip install

conda install

sudo conda install

some packages require one, are fine with other with few small warnings, and dont work with third way of installing.

If you’re installing a Python package into the global site packages directory (ie, into the system Python) you might need sudo. That’s how permissions work.

I don’t know the -u flag on pip, never used it can’t find it in the docs.

With a virtual environment sudo is not needed. Assuming you created it, and/or it is owned by you.

Virtual environments are just directories on disk. They are not complex.

I don’t use conda because it’s never felt even remotely necessary to me.

pip and a requirements file is all you need.

-u flag is short for --user ( https://stackoverflow.com/questions/42988977/what-is-the-pur... )

how about when you are authoring script under your name, but then want to schedule it for cron to run periodically?

I often find myself working under my user on remote server, but then I want to schedule cron job - and run into all sorts of permissions / bugs and missing packages.

especially when multiple machines need to run this script, and I don't want to involve containers to run 20-lines simple python script.

this is why Golang is so popular - you can just scp a single binary across machines and it will just work.

I’ve started packaging up my clients python scripts as docker images. Works great for cron tasks and updates/rollbacks are a breeze

I also forget a out:

1. pip install (with/out --user flag )

2. pip3 install (with/out --user flag )

3. sudo pip install

4. sudo pip3 install

5. conda install

6. sudo conda install

And because conda wasn’t enough, there are mamba and micromamba rewrites of conda in C++.

This is Stockholm syndrome

It’s one of the most popular programming languages in the world for a reason.

And the terrible package management story is not one of those reasons

correct, because it’s not terrible.

I routinely help data scientist people with mangled local python installs. It could be a full time job but a really bad one.