2

I'm having an issue where for some reason the virtual environments that I'm creating are accessing my system-wide installations of Python and pip when they shouldn't be.

Here's my fairly simple workflow just make sure I'm not missing anything obvious (Windows 10, Python 3.8.2):

python -m venv venv
venv\Scripts\activate.bat

My path is now prepended by (venv), as you'd expect. However, 

pip list

lists all of the system-wide pip packages I have instead of just the ones that should be in that venv.

pyvenv.cfg indicates that 

include-system-site-packages = false

When I open the interpreter using 

python

In the virtual environment, 

sys.executable

Returns the path on my C drive and

print(pip.__file__)

Does the same. I suspect they should instead be pointing to the interpreter and pip in the virtual environment but don't know how to make that happen.

Edit: 4/27/20, Still dealing with this issue, I have tried:

  • uninstalling and reinstalling Python, both from python.org and the MS Store

  • Installing python in a new location

  • Clearing my user and system environment variables and then adding in just the ones for Python 3.8.

I'm really at a loss here, would appreciate any help.

codydegen
  • 65
  • 6
  • May be this link will be useful for you: https://stackoverflow.com/questions/41573587/what-is-the-difference-between-venv-pyvenv-pyenv-virtualenv-virtualenvwrappe – Andrew Apr 27 '20 at 15:20
  • Thanks- did you have a specific part in mind? I have an understanding of what venv / virtual environments in general are trying to accomplish, my issue is that the intended function of the virtual environment itself is not coming about, which I don't see addressed in that question (i.e., activating the virtual environment does not point my python/pip to the virtual environment-specific installs of those programs, but continues to point to my global installations) However I may have missed something. – codydegen Apr 27 '20 at 15:41
  • I never had such issues with virtualenv... One additional question: which Python distrributive do you use? – Andrew Apr 27 '20 at 15:54
  • virtualenv runs into the same issue for me. I *think* the issue is more generally related to the paths set on my computer than the given package used as things worked correctly following the same workflow on another computer. I'm using Python 3.8.2 on Windows 10. – codydegen Apr 27 '20 at 16:02
  • Once more, what is the source of your Python? python.org? MS Visual Studio? Anaconda? MS Store? – Andrew Apr 27 '20 at 16:14
  • I've installed from both python.org and the MS Store. – codydegen Apr 27 '20 at 16:57
  • It can be a reason... From my point of view, original distributive is more standard. Suggestion is: remove both distributions, clean up system and user PATH and reinstall 64-bit Python from the python.org to the C:\Program Files\... Then update all outdated packages with pip (from the command line with admin rights), install virtualenv and forget about this strange error. – Andrew Apr 27 '20 at 18:16
  • I should probably add that information into the main post, but trying that previously has not fixed the problem either. I do appreciate your assistance with this. – codydegen Apr 27 '20 at 19:15
  • Do not bother, I like such quests. Additional information can be stored in appdata/..., including user site-packages, pip cache, etc, and in the registry. Also procmon from sysinternals can help... Did you manually cleanup Python directories in Program Files? – Andrew Apr 27 '20 at 21:02
  • Just went through and manually cleaned out all extra data from Program Files, appdata, roaming, etc. and unfortunately am still having the same issue. I'm not exactly sure what to look for in the registry but it appeared that when Python was uninstalled there were no extraneous entries. I'll be honest- I'm not too familiar with procmon or how it can help but I did download it and am happy to use it. I'll keep looking in the meantime but that's where I stand right now. – codydegen Apr 27 '20 at 23:09
  • Small advice - use filters to hide info from other processes. And I am sure that you will laugh when find a very simple error. Good luck! – Andrew Apr 28 '20 at 07:29
  • Just added a comment but figured you'd be curious to know the resolution- I realized that for some reason virtual environments were only exhibiting this behavior in a specific directory- one that just happened to be the place I store all my projects. I don't really know why this is, but I'm just happy to have figured it out. Thanks again for all your help- I really appreciate it. – codydegen Apr 28 '20 at 16:09
  • 3 possibilities: path is extremely long, it has non-ASCII characters (spaces?), or name of some element matches the name of any Python package etc. Please, publish it. – Andrew Apr 28 '20 at 16:40
  • I suspected it might be a space thing too but there weren't any in the path, which is C:\Users\Cody\Documents\Projects. Moving To C:\Users\Cody\Documents\Repo seemed to make things work but it's possible (likely) there's a confounding factor here I haven't considered. – codydegen Apr 30 '20 at 14:22

3 Answers3

1

To anyone looking at this later on, I eventually realized that the problem was only occurring in a specific folder. Making virtual environments elsewhere on my computer seems to work fine. Why this is the case? I have no idea. I'm curious, but not enough to spend another second on this problem. So there you go.

codydegen
  • 65
  • 6
1

This happened to me too. My problem was that I created the virtual environment under the directory including the global executable (I mean C:\Program Files\Python39). Once I removed this virtual environment and created a new one somewhere else (for example C:\Python), running python command took the executable in the virtual environment rather than the global one.

user2993624
  • 11
  • 1
0

I had the same problem too. It might be that the path to your virtual environment has a character with accent in it. This basically means that you will have to alter the \Scripts\activate.bat file. In order to see if that's the case, use the following procedure:

  1. Activate the virtual environment by running the file \Scrips\activate.bat
  2. Run the following command:
echo %PATH%

There should appear a bunch of paths, being path\to\your\virtual\environment\Scripts the first of them (this is obligatory). Check if this path is exactly the same as it is supposed to be (meaning it should have no "strange" characters instead of characters with accents). If there are any discrepancies, I suggest you alter your \Scripts\activate.bat according to https://stackoverflow.com/a/22348546/11923771, reopen your Command Prompt and follow steps 1 and 2 again to see if your problem was solved.

gabrielsilva
  • 31
  • 2