I have a virtual machine at my job running Windows 10 and there are a series of Python scripts being run on it via the Windows Task Scheduler. Obviously there is no documentation at my job on how these jobs were made and I am need of creating new jobs using the same process
When I use the command prompt to find where Python is installed:
C:\Users\Me>where python
I can see that it is installed at:
C:\Python36\python.exe
However, when I look at a task that is already on the scheduler, it is using a python.exe that is located in a completely different location. It is actually in the same directory that these particular scripts are in. Something like:
C:\DEV\A_Particular_Folder\This_Jobs_Environment\Scripts\python.exe
And then it is calling the main.py file:
C:\DEV\A_Particular_Folder\This_Jobs_Environment\main.py
I guess my question is, should each set of jobs/tasks have its own python installation? Is that why this task is not running python from C:\Python36\python.exe?
If that is the case, then why? And, how do I go about putting another installation in a new location that I would run my new jobs from without downloading it from python.org and running it like it's a new installation?
I tried installing from python.org and it seemed like it was going to overwrite what was already on the virtual machine.
Update: I just got done reading up on creating virtual environments and attempted that. I used:
python -m venv C:\DEV\BH_Test_venv
That did give me a new folder with a Scripts subfolder in it that has a python.exe. But, looking at other environments that are already set up, it looks like they all have a .idea and pycache subfloder in theirs. My venv command did not create those folders....
It is likely that they were previously set up using some sort of python virtual environment (or if they weren't, that is what you probably should do).
When you have different python scripts on a single machine, you want to avoid any dependency collisions. For example, if script one needs version 1.2.3 of a library but a different script, due to some other nested dependency, needs version 0.0.8 of that same script. If you have just a single python install, that wouldn't work (at least not easily).
The solution in python is to create a virtual environment. There are a number of ways to do it, I use the built in venv (more info in the python docs here: https://docs.python.org/3/library/venv.html). The basic idea is that the virtual environment is bound to the main python install but stores all third-party libraries (that you probably install via pip or conda) in an environment-specific location.
In my projects, I'll have a directory like this:
my_app
|__.venv/
|__app/
|__readme.md
|__etc etc etc
That .venv/ folder is created by first doing python -m venv .venv; that creates the folder and everything in it needed to run python with the libraries installed in that virtual environment.
My other projects or apps will then each have their own .venv/ folder. You can name the .venv whatever you want.
So then when you are using Task Scheduler, you don't want to run python from the system's default PATH, but rather from the virtual environment for that specific project so that you have the third-party libraries you installed into that virtual environment.
As a last note, the use of 'virtual' here with the python virtual environments is completely unrelated to the fact that you are using a Windows 'virtual' machine. One can use python virtual environments on any type of machine.