No (env) indication visible - Windows 10

[bkataru]

In all the time I've used virtualenv (i.e since 2 years now), whenever I activate a virtual environment there is an (env) indication like this:

But with the new virtualenv version (20.0.1), I have no indication of whether the virtualenv is active or not:

Was this intended? How do I get the previous functionality back? virtualenv version 20 seems much different than 16.

[gaborbernat]

This seems a regression here @BK-Modding. virtualenv 20 is a complete rewrite of 16, hence the big version jump. I believe things should still work. What shell are you running in there?

[pfmoore]

It looks like the .bat form of the activate script. That script does indeed look broken to me (the prompt setting says set "PROMPT=%PROMPT%" which is bizarre and the line endings seem broken).

[pfmoore]

There was code in the old version of virtualenv that replaced __VIRTUAL_WINPROMPT__ in the activate.bat script - that seems to have been lost in master.

[gaborbernat]

I'll try to address this but with a lower priority over other bigger bugs; if anyone has time to fix it feel free to submit a PR. Thanks! and sorry for the trouble it caused.

[bkataru]

@gaborbernat Thank you, I'm reverting to the venv module given by default in python until version 20 is polished a bit. This was the default windows cmd.exe shell.

[bkataru]

By the way, this is not that big of an issue but when I install virtualenv 20 it installs a bunch of additional packages like zipp, distlib, appdirs, etc. This use of additional dependancy packages wasn't present with virtualenv 16.

Again, not a big issue but apart from maintaining separate environments, one of the reasons why I use virtualenv is to prevent package bloat on my global pip installation and ironic that virtualenv is doing this. Will this use of additional dependancy packages ever be changed in future updates?

[gaborbernat]

By the way, this is not that big of an issue but when I install virtualenv 20 it installs a bunch of additional packages like zipp, distlib, appdirs, etc. This use of additional dependancy packages wasn't present with virtualenv 16.

This well might be, but needing to write everything ourselves and vendoring those, was a major pain in the maintenance of the package, and lead to the package being mostly abandoned for significant portions of times.

Again, not a big issue but apart from maintaining separate environments, one of the reasons why I use virtualenv is to prevent package bloat on my global pip installation and ironic that virtualenv is doing this. Will this use of additional dependancy packages ever be changed in future updates?

We definitely don't recommend you installing virtualenv into the global pip installation. You should either use pipx or the zipapp; see https://virtualenv.pypa.io/en/latest/installation.html#via-pipx for more details.

[bkataru]

@gaborbernat ah I see. Thank you.

[gaborbernat]

Hello, a fix for this issue has been released via virtualenv 20.0.8; see https://pypi.org/project/virtualenv/20.0.8/ (https://virtualenv.pypa.io/en/latest/changelog.html#v20-0-8-2020-03-04). Please give a try and report back if your issue has not been addressed; if not, please comment here, and we'll reopen the ticket. We want to apologize for the inconvenience this has caused you and say thanks for having patience while we resolve the unexpected bugs with this new major release.

[bkataru]

@gaborbernat Yep the new release works similar to the old virtualenv versions. Thank you for the fix and support :D

[gaborbernat]

@spetafree did most of the heavy lifting on this one