The issue is likely that you use one version of pip and another version of the Python interpreter. This is particularly common if you have several Python installations on your system. Check that these versions match with each other.
For example, run
python --version
pip --verion
You should see output similar to the following:
Python 3.10.2
pip 22.1.2 from /Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/pip (python 3.10)
Notice the matching version numbers. I am verifying this on my system with Homebrew, under MacOS, but I assume that it's similar on other systems. Here, different instances of "python" and "pip" binaries are suffixed with the version number. So, if your version of "pip" says "3.8", try specifying "python3.8" as interpreter.
It might also be helpful for troubleshooting to know of the "-m" switch, in order to locate a module. In your example, you would run:
python -mPyFoam
Notice the capitalization for this module, which can differ between the one being used to install the module through pip and when importing it. On my system, as an example, it outputs:
/Library/Frameworks/Python.framework/Versions/3.10/bin/python3: No module named PyFoam.__main__; 'PyFoam' is a package and cannot be directly executed
The error message is fine. It does still mean the module was found. That is in contrast to an output like the following:
/Library/Frameworks/Python.framework/Versions/3.10/bin/python3: No module named pyfoam
The -m switch is documented under https://peps.python.org/pep-0338/.
Another possibility might be that you need to check and configure your Python module search path, as described here https://docs.python.org/3/tutorial/modules.html.
When a module named spam is imported, the interpreter first searches
for a built-in module with that name. These module names are listed in
sys.builtin_module_names. If not found, it then searches for a file
named spam.py in a list of directories given by the variable sys.path.
sys.path is initialized from these locations:
The directory containing the input script (or the current directory
when no file is specified).
PYTHONPATH (a list of directory names, with the same syntax as the
shell variable PATH).
The installation-dependent default (by convention including a
site-packages directory, handled by the site module).
Note On file systems which support symlinks, the directory containing
the input script is calculated after the symlink is followed. In other
words the directory containing the symlink is not added to the module
search path. After initialization, Python programs can modify
sys.path. The directory containing the script being run is placed at
the beginning of the search path, ahead of the standard library path.
This means that scripts in that directory will be loaded instead of
modules of the same name in the library directory. This is an error
unless the replacement is intended. See section Standard Modules for
more information.
It's possible to try to think of other causes. But without any additional information about your setup it would probably be too speculative and become confusing for other people reading this answer, so I will leave it at these two causes, which I believe to be the most common for this type of issue.