# Why do I get "Module not found" after python installation in venv?



## Aroflote (Nov 9, 2022)

Hello

Goal
My goal is to set up a Python application in a virtual environment in FreeBSD, and run it from there.

Setup
I have created the virtual environment, activated it, installed pip within this and ran
`pip install -r requirements.txt`
The installation went well, and I could list out all installed packages with
`pip list`

Problem
With this, I tried to run the project with `python app.py`, but I get the error
`ModuleNotFoundError: No module named 'dash'`
(dash is the first module in use in my application)

My question is then: *Why do I get this error?*

Extra information

I run FreeBSD (64-bit) 13.1 on a Virtual Machine (VirtualBox)
My host is a MacBook Pro with Ventura 13.0
I have Python 3.9.15 (installed globally)
I have pip 22.3.1
What I tried

I can verify that dash is installed within the same folder and venv I try to run the application in with `pip show dash`
I tried installing dash through `pkg install dash` as well, after looking at this thread.
The installation went through, but I'm pretty sure it's the wrong dash.

If I have misunderstood anything in the Python/Pip/Venv/FreeBSD combination, I apologize.

Thanks


----------



## Alain De Vos (Nov 9, 2022)

Maybe

```
pip-3.9 install --user dash
```


----------



## Aroflote (Nov 9, 2022)

Alain De Vos said:


> Maybe
> 
> ```
> pip-3.9 install --user dash
> ```



I would prefer to keep the installation within the virtual environment. Unless this is not possible?


----------



## Alain De Vos (Nov 9, 2022)

I think it is,
python3.9 -m venv tutorial-env 
source ./tutorial-env/bin/activate
(tutorial-env) >pip3.9 install dash


----------



## cmoerz (Nov 9, 2022)

Did you verify whether your `pip` and `python` command runs in the venv? You should be able to verify that .venv/bin (or whatever the name of your venv directory) holds matching symlinks - i.e. does `pip` and `python` point to the right executables?
Plus, I assume that activation properly puts that bin directory at the top of your PATH variable?


----------



## Aroflote (Nov 9, 2022)

Alain De Vos said:


> I think it is,
> python3.9 -m venv tutorial-env
> source ./tutorial-env/bin/activate
> (tutorial-env) >pip3.9 install dash


Yes, this is something similar to what I did when i created and activated the virtual environment


----------



## Aroflote (Nov 9, 2022)

cmoerz said:


> Did you verify whether your `pip` and `python` command runs in the venv? You should be able to verify that .venv/bin (or whatever the name of your venv directory) holds matching symlinks - i.e. does `pip` and `python` point to the right executables?
> Plus, I assume that activation properly puts that bin directory at the top of your PATH variable?



I get the following results, hoping this is somewhat what you asked for mentioning the executables.
It seems like the paths of the venv python3 and pip match each other:


```
//Globally
$ whereis python3
python3: /usr/local/bin/python3
$ whereis pip
python3: /usr/local/bin/pip

//In activated venv
$ whereis python3
python3: /usr/home/sshuser/sw-ui-server/gui-venv/bin/python3
$ whereis pip
python3: /usr/home/sshuser/sw-ui-server/gui-venv/bin/python3
```

It seems like the path is correct as well when the venv is activated:


```
$ echo "$PATH"
/usr/home/sshuser/sw-ui-server/gui-venv/bin:
/bin:
/usr/sbin:
/usr/bin:
/usr/local/sbin:
/usr/local/bin:
/home/sshuser/bin
```


----------



## astyle (Nov 9, 2022)

Which 'Virtual Environment' is OP using? There's jails, bhyve, and virtualbox, just to name a few. And they all have rather different ways to communicate with the host. I had to re-read the thread a few times before realizing that OP is talking about jails.

In a 'jailed' environment, specific processes are restricted to using a specific set of folders.  In case of jails, it's possible to use the host's python install - or install a different version of Python that is limited to the jail. Jails offer flexibility with exactly what path (that lives on bare metal) gets mounted inside the jail.

It boils down to keeping track of exactly where you run the very first command - was it on bare metal or inside the jail?

If OP wants to install something in a jail via pip, then probably the first step is to make sure that pip (and by extension, python) is functional _inside the jail_. Then, while still inside the jail, run that `pip install whatever` command. If you run that command outside of the jail, you can't really expect that the jail will pick it up. This is frankly by design - and can be put to good use, depending on the project at hand.

I think that OP would benefit from studying the Handbook's chapter on jails. The example is not using Python as a demonstration, it will take some thinking to connect the dots there.









						Chapter 16. Jails
					

Jails improve on the concept of the traditional chroot environment in several ways




					docs.freebsd.org
				




But basically, to solve OP's problem, I think OP just needs to be still inside the jail when running the `pip install` command.  Then, while still inside the jail, run the Python program. 

Don't try to figure out the path mounting from metal. Just ssh into the jail, and finish the install.


----------



## ralphbsz (Nov 9, 2022)

astyle said:


> Which 'Virtual Environment' is OP using?


Python has its own virtual environments. They have nothing to do with OS-level constructs you listed. They reach the same goal (having multiple applications run on the same machine, with different set of libraries = modules) in a different way. Documentation is here: https://docs.python.org/3/tutorial/venv.html

I tried them once for 10 minutes, and decided that they're not for me. I'd rather keep all my modules up-to-date system wide, and if an application has a problem with that, fix the application, rather than deliberately run obsolete modules. But to each their own.


----------



## astyle (Nov 9, 2022)

ralphbsz said:


> Python has its own virtual environments. They have nothing to do with OS-level constructs you listed. They reach the same goal (having multiple applications run on the same machine, with different set of libraries = modules) in a different way. Documentation is here: https://docs.python.org/3/tutorial/venv.html
> 
> I tried them once for 10 minutes, and decided that they're not for me. I'd rather keep all my modules up-to-date system wide, and if an application has a problem with that, fix the application, rather than deliberately run obsolete modules. But to each their own.


Well, TIL...


----------



## Aroflote (Nov 9, 2022)

ralphbsz said:


> Python has its own virtual environments. They have nothing to do with OS-level constructs you listed. They reach the same goal (having multiple applications run on the same machine, with different set of libraries = modules) in a different way. Documentation is here: https://docs.python.org/3/tutorial/venv.html
> 
> I tried them once for 10 minutes, and decided that they're not for me. I'd rather keep all my modules up-to-date system wide, and if an application has a problem with that, fix the application, rather than deliberately run obsolete modules. But to each their own.



This is the virtual environments I use, yes. Sorry if I wasn't clear.
I wasn't familiar with the other "virtual environments", although I believe the purpose is the same as you point out.

There are of course advantages of keeping packages up-to-date globally, and it works as long as you are in control. I have familiarized myself with using Python venvs whenever I work on a Python project. The projects are not always my own, and may require other package versions than I have installed globally. Having two installations then often become confusing and complicated to keep free from errors.

In the case I have presented here, I may however end up installing globally due to how I plan to use my FreeBSD system (together with the `--user` flag when installing, as I've seen people recommend when using pip)

In the future, it would however be great to be able to use Python venvs within FreeBSD as I think it is a practical tool well known to Python users. If Python venvs is not supported, but it is possible to acquire the same behavior with i.e. jails, that could also work.


----------



## astyle (Nov 10, 2022)

In the past, when I tried to use `pip install`, I noticed that it does make a difference if you run it as `root` (instead of reg user). Just another gotcha from the UNIX world...


----------

