A while ago I wrote a python schedular that calls another python file every hour on the hour. Using os.system(‘xxxx.py’)
The first line of the xxxx.py file is
import requests
Up until about a week ago this was working fine.
Now, I get an error as soon as the file is called as follows:-
Traceback (most recent call last):
File “xxxx.py”, line 1, in
import requests
ModuleNotFoundError: No module named ‘requests’
The xxxx.py file runs well when started manually.
I am at the end of my knowledge now.
What OS are you using Windows?
Are you using venv?
Have you installed a new version of python recently?
Have you checked that requests is installed? python -m pip list
When you run xxxx.py from a terminal what happens?
When providing terminal output and code please use the </> button (or type 3 backquotes) to format the text preserving spaces etc.
Thanks for the reply. I’m new to this group so sorry for the dodgy protocol
OS is Windows 10 22H2
No venv involved
I’ve tried it on 2 different machines. Python versions 3.10.2 and 3.11.1. No python updates done recently and, as I said, was working perfectly until about a week ago. Maybe due to a windows update I guess as these are automatic. (Guessing)
pip list checked and can confirm presence.
Running from terminal and direct from any ide it runs OK. It is only when called from the other script that it fails…
///
Traceback (most recent call last):
File “xxxx.py”, line 1, in
import requests
ModuleNotFoundError: No module named ‘requests’
///
I can’t understand why it works directly but not from an OS call.
Because when you do the os.system call, it works like if you typed that exact string at the command line; whereas when you use it directly, it works according to the command line you wrote for using it directly. A command like xxxx.py means to let Windows use its logic to decide which application to open it with (that doesn’t even have to be Python). A command like python xxxx.py means to let Windows use its logic to decide which Python executable that means, and then run it, and then the Python program uses its logic to open the file. A command (on Windows, with the py launcher installed) like py xxxx.py means (even when a virtual environment is active) to run the py program (it’s put into Windows’ own folder, so there is no ambiguity) and use its logic to choose a Python executable, which then takes over.
You have more than one Python executable; therefore, it matters which one is chosen to run the file. Every installation of Python (even if it’s a duplicate of the same version, and whether or not it’s part of a virtual environment) gets its own places for third-party content, and (potentially) its own Pip, which installs to those places. Separate installations of Python cannot share third-party content (unless you modify PYTHONPATH and “void your warranty” by accepting that the third-party content might not be compatible with the Python version for the other installation).
Similarly, pip list and python -m pip list and py -m pip list could use different Python installations, and therefore different Pip installations, and therefore look at different sets of third-party content.
My guess is that “about a week ago” is when you either added the second installation of Python; or modified xxxx.py to use Requests and installed Requests for one of those Pythons; or uninstalled Requests from one of those Pythons when it was previously installed separately for both. (Or rather, when you first tried the program, after one of those things happened.) It seems fairly unlikely that a Windows update would change your system’s Python file associations - unless, perhaps, either or both of those Python installations is the Windows Store installation. But I’m only guessing there; I gave up on Windows years ago.
To diagnose the problem, you should start by making sure you understand how to verify which Python is being used for a running Python program: