Pipenv "ModuleNotFoundError: No module named 'numpy'" windowsOS/pipenv shell

Hi, I am currently taking the computer science course and I am in the pipenv section of modules. I was hoping I can get some feedback when all of the StackOverflow results I get are very specific I hope my issue isn’t a difficult one. Every time I try to import the module I just get an error of it not being found.
It is shown in the pipfile and pipfile.lock same versions also. Even when I run the version of pipenv I get the right version.
(I am in the pipenv shell – windows OS)


1 Like

You have two different versions of Python. 3.9.10 and 3.9.7. Which one did you install numpy in? Was Python added to the PATH variable?

Perhaps one of these threads could be of some help?


Or, this?


So I suppose my python version is 3.9 for numpy

Make sure you activate the new pipenv environment beforehand or you’ll be working with the default/system python. Typically done with pipenv shell.

1 Like

Even my default shell wont work D: I thinking it might be pathing issues

I have my path set to this file specifically

It’s possible but it shouldn’t matter once inside a virtual environment. I’d highly suggest sticking with pipenv install or pip install rather than swapping between the two or you’re just adding a layer of potential confusion. The same with running python and python3 (they might not be linked to the same executable). If you’re not 100% sure what they’re linked to you’ll want to find out.

Try python -m site for a detail on where the current python interpreter is looking for modules and libraries. Then try within your pipenv environment, they should be different. The locally activated virtual environment (from pipenv) should take precedence over anything else on your PATH.

As for fixing up the rest of your PATH if there’s a problem at least python -m site will tell you where it’s looking.

All things `

python -m site

` it saying that these do not exist is this a problem?
I also moved up the environment variable all the way to the top to take precedent over everything else.

I’m hoping this solution helps others too because I can’t be the only one…

The fact the user specific files for a top-level install don’t currently exist shouldn’t matter. It’s only when you install user-specific packages pip install --user that it would start to matter (it normally builds a folder itself when doing that anyway). Since I get the impression you’re trying to use a virtual environment it’s quite possible to have the basic Python install without any third party packages (be that in ...\python3.9\\site-packages or the user site packages).

What about the module loading path inside the virtual environment you’re using (after you’ve activated it with pipenv shell)?

You don’t need the basic Python install at the top (though it’s up to you if you want it there). The standard scripts for activating a virtual environment would bump the virtual environment’s third-party packages (which are different to the main install) to the front of your PATH whenever you activated that environment anyway.

Thank you for clearing that up for me I will keep it at the top for now until I get this figured out.

These are the locations I get inside my virtual environment and on my vsCode IDE.
Also, I know I’m taking up a lot of your time and this shouldn’t take precedent, I am willing to come back to this tomorrow if no solution arrives.
pathing? maybe

Might be helpful too?

1 Like

That looks about right to me for activating a pipenv based environment in that folder, the relevant packages now link to something different.

The overall system PATH does seem a bit confused (there’s a normal Python install and one from msys). It’s really unclear where pipenv is coming from too. Chances are that’s going to be a pain at some point (probably what’s making this harder than usual) but that shouldn’t matter in the context of an activated virtual environment (hopefully).

Once you’re-
a) in the right project location
b) have an activated pipenv environment (pipenv shell)
c) have installed numpy with pipenv (pipenv install numpy)
then you should be about there.

Try using python (NOT python3) for the interactive interpreter and then import numpy.

Just to make sure it’s clear be very careful about jumping between python3 and python when invoking scripts. There’s no guarantee they’re linked to the same thing. The fact pipenv works but python3 -m pipenv doesn’t is very suggestive. This also goes for pip and pipenv, python -m pip, python -m pipenv, python3 -m pip, python3 -m pipenv and so on…

Easiest option, use the virtual environment and just use python.

If you get the time dealing with all the system installs you have would be a good idea as it’s inevitably making this much harder.

1 Like

it was switching between


and python. I have never seen just


used before so it was my problem jumping into python3 to invoke scripts. Took me two hours and 30 minutes but I’m not mad lol. I’ll take this as a form of experience. If there is anything I can do to thank you more let me know! Glad to see there are still wonderful people out there that can be patient with beginners trying to learn. Something I live by is the word ignorance derogatory as it sounds I embrace it.

1 Like

It’s all good, the whole thing with virtual environments has always been a bit of a mess and it’s especially hard for folks who are new to the command line & shells in general (if you get some time taking a course on it might make several things easier in the long term).

As for using python3 It’s quite common on the OSX/Linux side of things since many of them have Python installed as part of the system which is often still python2.x. Since python’s already installed but you want your shiny new python3.x (rather than the system) version many on the *nix side just use python3 instead (and leave python linked to the system python2.x). But they often run into walls when using pip on its own since that’s normally linked to python2 so python3 -m pip may be necessary.

On Windows it’s less important as there’s no Python in the default system (or if there is it’s hidden well away from users). So you can often just use python once you’ve installed a version of it. It’s a bit trickier when you have more than one install and you start needing to look after the system PATH to ensure the right version is used (and the right packages too). Virtual environments aren’t perfect but they’re a slightly easier way of trying to look after it all (and perhaps more importantly, when publishing code).

Using python also goes for many virtual environments that add their version of python to the front of the path so that invoking python links directly to the envrionment’s python3.x instead of whatever it used to. It’s just a case of precedence in terms of the PATH (and sometimes aliases which would be ahead of the path again).

I was a little surprised that the pipenv environment on Windows doesn’t also mask python3 with a link to the higher precedence virtual environment version but perhaps they expected they didn’t need to (I couldn’t say for sure). That’s roughly how it all goes though.

1 Like