Pipenv - Virtual Environments have wrong builds

Hi there!

I am following along the Data Analyst path and have arrived at the video regarding virtual environments. I have no problems with the video and have managed to create two separate virtual environments. The problem is that when I run the shell command and try and check which versions of each module are installed, they don’t seem to match the build versions that are in my Pipfiles.

I have copied my code below so that you can see what I have done.


C:/…/project1> pipenv shell
Launching subshell in virtual environment…
PowerShell 7.1.2
Copyright (c) Microsoft Corporation.

Type ‘help’ to get help.

Loading personal and system profiles took 639ms.
(base) PS C:…\project1> python3
Python 3.7.9 (tags/v3.7.9:13c94747c7, Aug 17 2020, 16:30:00) [MSC v.1900 64 bit (AMD64)] on win32
Type “help”, “copyright”, “credits” or “license” for more information.

import requests
print(requests.version)
2.25.1


Below is the Pipfile for project1:


[[source]]
url = “https://pypi.org/simple
verify_ssl = true
name = “pypi”

[packages]
numpy = “*”
requests = “==2.18.1”

[dev-packages]

[requires]
python_version = “3.9”


As you can see, my Pipfile has requests set to version 2.18.1 but the version my pipenv loads for this project is 2.25.1. I don’t understand what I’ve done wrong…

Thanks in advance!
Karl

At a guess it’s falling back to using a different virtual environment, based on the name being (base) I’ll assume that’s a conda virtual environment?

You can check the currently activated virtual environment used by pipenv with-

pipenv --venv

Do you have a terminal window option where the conda commands are not sourced by default? I’ve not tried mixing pipenv and conda much but it sounds like a potential headache if you’re trying to install multiple different versions of Python too :open_mouth:.

A possible solution without digging into your PATH (this is a short term solution, long term you’d want to sort this out properly!) is to create this virtual environment directly in your project. There’s a short discussion on how here-

That’s not the only option but it seems like it might be the easiest.

Edit: If your python install isn’t on your PATH then you may also want to use the full filepath when creating the environment with pipenv to make sure it uses the 3.9 version you have. Something like the the following might be necessary-

pipenv install --python C:\Python\python39\python.exe
# you'll need the correct filepath for this, above is an example only

Personally I prefer this method anyway (each project has it’s own environment stored locally in that environment, simple and effective). If using version control you may want to add the environment to .gitignore or the equivalent for what you’re working with as you probably don’t want to try and track multi-GB site-packages :slightly_smiling_face:.

1 Like

Thanks for the quick reply!

I found out the activated virtual environment being used, followed the directory path went into the folders installed packages: C:\Users\Karl.virtualenvs\project1-EDEQ8Q26\Lib\site-packages
The installed request package is for the correct build (2.18.1)
This is everything inside the version file:


.-. .-. .-. . . .-. .-. .-. .-.

|( |- |.| | | |- -. | -.

’ ’ -' -.-’ -' -’ ’ `-’

title = ‘requests’
description = ‘Python HTTP for Humans.’
url = ‘http://python-requests.org
version = ‘2.18.1’
build = 0x021801
author = ‘Kenneth Reitz’
author_email = ‘me@kennethreitz.org’
license = ‘Apache 2.0’
copyright = ‘Copyright 2017 Kenneth Reitz’
cake = u’\u2728 \U0001f370 \u2728’

My terminal still prints the version as the incorrect version though…
Scratching my head here haha

When you ran python in powershell it seems to be opening a different version of Python to what you expect (your Pipfile stated 3.9)-

pyython3
Python 3.7.9

So I’m not too surprised the site packages don’t line up either. Somehow you’ve still got the wrong version of Python at the head of your PATH and the wrong site packages probably at the start of your pythonpath.

It still seems to be running a conda environment instead of your pipenv one. Your prompt should have by default the folder name prepended (not base which suggests conda)-

(Project1) PS C:…\project1> 

This means that conda’s distribution of Python and conda’s environment site packages are being used. You really want to make sure conda isn’t sourced by default unless that is what you want, this will probably keep causing issues.

Based on what you describe you might be able to get your environment sourced by first deactivating the conda environment and then directly sourcing the correct environment-

conda deactivate
C:\Users\Karl.virtualenvs\project1-EDEQ8Q26\Scripts\Activate.ps1

But that’s drifting into guesswork, you really want to fix the conda set-up.

I’ve fixed one problem and created 10 more :joy:
So I’ve managed to stop conda from sourcing by default and my Powershell correctly shows Python3 running with 3.9.
I think you were right with it being a problem with my conda set-up, so I have been trying to uninstall conda and reinstall it correctly, however I’m having difficulty. I’ve read article after article online and nothing seems to be working. How do I uninstall conda fully from my PC, then reinstall it correctly? I think the problem is that I’ve installed packages into a bunch of different places and it’s causing issues…

1 Like

Apologies, I have reinstalled conda with the correct settings. The problem I have now is when I generate the virtual environment the terminal doesn’t recognize the module requests:

PS C:\Users\Karl\Documents\Coding\Codecademy\Data Analyst\Virtual Env\project1> pipenv shell
Launching subshell in virtual environment…
PowerShell 7.1.3
Copyright (c) Microsoft Corporation.

Type ‘help’ to get help.

PS C:\Users\Karl\Documents\Coding\Codecademy\Data Analyst\Virtual Env\project1> python3 --version
Python 3.9.5
PS C:\Users\Karl\Documents\Coding\Codecademy\Data Analyst\Virtual Env\project1> more Pipfile
[[source]]
url = “https://pypi.org/simple
verify_ssl = true
name = “pypi”

[packages]
numpy = “*”
requests = “==2.18.1”

[dev-packages]

[requires]
python_version = “3.9”
PS C:\Users\Karl\Documents\Coding\Codecademy\Data Analyst\Virtual Env\project1> python3
Python 3.9.5 (tags/v3.9.5:0a7dcbd, May 3 2021, 17:27:52) [MSC v.1928 64 bit (AMD64)] on win32
Type “help”, “copyright”, “credits” or “license” for more information.

import requests
Traceback (most recent call last):
File “”, line 1, in
ModuleNotFoundError: No module named ‘requests’

There is definitely a requests folder in the directory that pipenv --venv listed…

1 Like

It’s not the most important thing but your prompt still doesn’t change so I’m wondering if that environment is being sourced at all. I’d be tempted to delete it and try the pipenv install step again.

You can double check what’s on the the module import path with something like-

python -c "import sys; print(sys.path)"

I would expect (or rather hope) the only site-packages (other paths will be there of course but not site-packages specifically) listed would be something like-

'C:\Users\Karl.virtualenvs\project1-EDEQ8Q26\lib\site-packages'

It seems like something else is being used.