[andrewflnr]

> having to remember where they were, what their names were, and what was installed into each one was a pain point for me.

It's at the project root, it's named 'venv', and its contents are described by requirements.txt.

> You're saying you see people complain about it a lot - therefore it's a genuine problem.

Debatable as a principle, but applicable enough here I suppose. Still, I'm not saying the problems aren't real, but what I (and probably most of us virtualenv users) are saying is that there's a pretty broad swathe of projects where you don't encounter them. It's just fine. You install your packages and use your packages and that's the whole story.

I guess if you have a hard dependency on a particular version of python, it's going to be harder, but... why? That's already niche in my book. If you're saying the AWS repo was pinned to a particular version of python, I'm going to blame that on Amazon frankly. That's definitely bizarre.

Edit: Were you looking at this? https://github.com/boto/boto3 Definitely more complicated than a typical greenfield virtualenv-able project, with some python version restrictions.

[awesome_dude]

> what I (and probably most of us virtualenv users) are saying is that there's a pretty broad swathe of projects where you don't encounter them.

Zero. The required number of problems needs to be zero - hence my OP

> I guess if you have a hard dependency on a particular version of python, it's going to be harder, but... why?

The bigger question is - why doesn't 3.9 compile and run 3.8

Further, in what world is targeting a specific runtime version in an enterprise production environment "niche"?

When you are deploying to managed corporate infrastructure, AWS Lambda runtimes, or strict Docker base images, you don't just get to loosely target "whatever Python version happens to be on the developer's laptop." You target an exact runtime version (e.g., Python 3.10) because language syntax, standard library features, and performance characteristics change between minor releases.

The fact that Python forces the developer to manually manage isolated directory symlinks (venvs) just to prevent local environment contamination — and that minor runtime mismatches can completely derail a standard onboarding experience — is a structural UX failure.

[andrewflnr]

> Zero. The required number of problems needs to be zero - hence my OP

This is unrealistic. You seem to have moved to Go as an alternative, but I know because I've seen the complaints that Go doesn't satisfy that standard either.

[awesome_dude]

I explictly say that NO dependency management is without problems, AND call out Go's attempts in my OP.

You came barrelling because your favorite tool is mentioned, and then, when you realize that it deserves the criticism you try and play that?

Maybe, just maybe, take an objective look at the real problem (dependency management) and recognise that, as stated, nobody has solved it.

[andrewflnr]

I was trying to be sympathetic and acknowledge virtualenv's potential flaws, actually, even though I haven't personally encountered them, but I guess that was a waste of time.

[awesome_dude]

Which part of this is sympathetic?

> This is unrealistic. You seem to have moved to Go as an alternative, but I know because I've seen the complaints that Go doesn't satisfy that standard either.

It's a dig - you completely ignore the valid complaints about Python to instead focus on what you think will provoke me.

The problem (for you) was, from the very start, I bought up the pain points with Go.

[andrewflnr]

> Still, I'm not saying the problems aren't real, ...

> I'm going to blame that on Amazon frankly. That's definitely bizarre.

I'll grant I lost track of the context that you were trying to raise the possibility of some grand encompassing solution to all programming language package management. All I wanted was to reinforce the idea that virtualenv is Often Just Fine in practice, at least if used in sensible ways.

[dxdm]

Only if you let it. I learned something from the response to my question.

Folks, take a step back, both of you. It's just software.