It depends on who you're talking about. There is an attitude of, "if you can't install a virtualenv as step 1 in learning how to do python, you don't deserve to learn python". Not, I would hope, consciously thought of in that way, but that's the practical affect.
I use virtualenv. When I was first learning to program, and I believe python is a better choice for a first language than PHP or Javascript, it would have been a substantial obstacle to have to do the virtualenv route first. Yeah, it's easy if you've done it and know how to figure out what the problem is if something goes wrong. It's an obstacle if you're just starting out, and I think keeping the on-ramp simple is very important for the long-term health of a language community.
Which suggests that, because python's on-ramp just got easier, it's long-term prospects just got better.
If you're just learning, you don't need to mess around with virtualenvs; you can install Python via the official Windows installer and install packages globally. I don't feel like installing something is a very big initial hurdle to overcome, as opposed to having it be pre-installed (but potentially very outdated in the future).
On the contrary, installing something is the biggest hurdle after perhaps coming up with the idea that there's something here to be learned at all. And sometimes it's part of the latter.
Well, I don't have that attitude. Lately, I push beginners towards repl.it so that they don't need to install anything or setup an IDE. There, each script/program is completely separate. So it avoids this issue entirely. Then, when they're a bit more familiar with programming, they can transition to a good local environment like PyCharm or some other setup that manages python versions, virtualenvs, etc.
What I'm saying is that bundling a specific Python interpreter and separate package environment should be the default. I'm not sure what it'd take to get there for a vanilla python install. But more system-level interpreters is not it.
Currently, the way I know of to do that is pyenv [0]. And I know PyCharm let's you pick a python version when you start a project (though I don't use pycharm so that may not be true anymore).
> I use virtualenv. When I was first learning to program, and I believe python is a better choice for a first language than PHP or Javascript
I’m a seasoned programmer and I absolutely hate how you’re forced to use VirtualEnv with python. One of the absolutely biggest warts of its already poor package-management.
It literally makes everything which should be simple, something you suddenly need to handle. Atrocious.
I like it much better like .Net, Node or Rust (and many others) where the dependencies are entirely handled within a project, completely obsoleting the need for a hack solution like virtualenvs in the first place.
I always felt that virtualenv is vastly superior to most other package managers. I think comparing it to Rust and .Net is a little unfair, as these are compiled languages and have different deployment models.
When I was first learning and there was a system Python I would install packages, then 6mo to a year later I would find something old. Because the OS came with Python and some number of libraries and because I modified that somehow, I couldn't get back to a known state without reinstalling my OS or updating/removing things likely causing problems. Everything I did were separate test projects, so it never made sense to install libraries globally.
Even now for many languages I shy away from installing globally (I usually install to user if I'm lazy). I feel like in almost any language a "project" (venv) should be taught early on and be simple to use. Basically, the first time you need a third-party module. I feel like newcomers should be shown the REPL, how to save code to a file and run it, standard libraries, then a workspace and how libraries work. Python could be a great example because of the batteries-included model I don't need external libraries for many tasks.
First step of creating a hello world Node.js application is to write a package.json file which is somewhat equivalent of virtualenv. Nobody ever complained about that. Isolated packages per project becomes the default and not an obscure extra command. Same with Rust, Gradle and many others.
I would like to reverse the question. If you can't install a virtualenv as step 1, the process of creating a virtualenv is simply too difficult and should be streamlined.
I use virtualenv. When I was first learning to program, and I believe python is a better choice for a first language than PHP or Javascript, it would have been a substantial obstacle to have to do the virtualenv route first. Yeah, it's easy if you've done it and know how to figure out what the problem is if something goes wrong. It's an obstacle if you're just starting out, and I think keeping the on-ramp simple is very important for the long-term health of a language community.
Which suggests that, because python's on-ramp just got easier, it's long-term prospects just got better.