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

Aroflote

Aroflote

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
 
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?
 
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?
Click to expand...

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:

Code: 
//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:

Code: 
$ 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
 
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.
docs.freebsd.org

Chapter 17. Jails and Containers

Jails improve on the concept of the traditional chroot environment in several ways
docs.freebsd.org 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.
 
astyle said:
Which 'Virtual Environment' is OP using?
Click to expand...
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.
 
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.
Click to expand...
Well, TIL...
 
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.
Click to expand...

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.
 
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... ?
 
You must log in or register to reply here.
Back
Top