Practical Workflow Automation - the local Python path (Windows first) ===================================================================== The course is completed in the browser. This path is optional, and it is where you do the three things a browser cannot: work with real files on your own disk, make an optional live request, and install a real scheduled task. Nothing here needs an account, a credential, or a paid service. Checked against the official Python documentation for Windows and Microsoft's schtasks reference on 2026-09-09. If a command below disagrees with those, believe the documentation and not this file. 1. Install Python ----------------- Windows. The Python Install Manager is the current recommended way to obtain Python from the CPython team; it is available from python.org/downloads and from the Microsoft Store. The older full installer is deprecated as of Python 3.14. Once it is installed, `py` is the command to use everywhere in place of `python`: py --version py -V:3.14 run a specific version py install manage installations py list see what is installed macOS and Linux: use your usual package manager or python.org, and `python3` in place of `py` throughout. 2. Make a practice folder ------------------------- Do this. Do not point any of these programs at a folder you care about. mkdir %USERPROFILE%\automation-practice cd %USERPROFILE%\automation-practice mkdir inbox archive quarantine output state Copy the downloaded .py files and sample-orders.csv into that folder, and put a few harmless files into `inbox` to practise on. Text files you create yourself are ideal. 3. Make an environment for the project -------------------------------------- py -m venv .venv .venv\Scripts\Activate That one command works in both PowerShell and Command Prompt, and it is what the official Windows documentation gives. Your prompt gains a `(.venv)` prefix when it has worked. (Verified on Windows 11 with Python 3.14: PowerShell resolves the bare name to `Activate.ps1` and Command Prompt to `activate.bat`, so you do not need to type either extension.) If PowerShell refuses with "running scripts is disabled on this system", that is the execution policy, not a problem with your environment. Allow scripts for this one terminal session and try again: Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned `-Scope Process` lasts until you close that window and changes nothing for the machine or for other users. Command Prompt is unaffected either way, because `activate.bat` is not a PowerShell script. These programs use only the standard library, so there is nothing to install. The environment still earns its place: it fixes which Python runs, which is the difference between a script that works in your terminal and fails under the scheduler. 4. Run something, in the safe mode first ---------------------------------------- py starter_organise_inbox.py --folder inbox That is the dry run, and it is the default. It lists what it would do and changes nothing. Compare the folder listing before and after; they must be identical. When you are satisfied with what it says it would do: py starter_organise_inbox.py --folder inbox --apply 5. Schedule it, and then remove it ---------------------------------- Start with something trivial, watch it work, and delete it. The point of this step is to meet the surprises now rather than at three in the morning. Create a task that runs every five minutes: schtasks /create /sc minute /mo 5 /tn "automation-practice" ^ /tr "C:\full\path\to\.venv\Scripts\python.exe C:\full\path\to\starter_daily_digest.py --folder C:\full\path\to\automation-practice" /f Check what was actually created, and run it once by hand: schtasks /query /tn "automation-practice" /v /fo LIST schtasks /run /tn "automation-practice" Remove it when you are finished, and confirm it is gone: schtasks /delete /tn "automation-practice" /f schtasks /query /tn "automation-practice" The last command should report that the task does not exist. Do not skip it: a forgotten five-minute task from an experiment is a small permanent background process on your machine. Notes that matter: - Use absolute paths for the interpreter, the script, and any folder. A scheduled task does not start in the directory you expect. - `/sc daily /st 02:00` is the shape for a nightly job; `/sc minute /mo 5` is for this experiment only. - `/f` suppresses the prompt when a task of that name already exists. - A task that runs as you, on your own machine, does not need administrator rights. A task that runs as the system account does. - Microsoft documents that schtasks may ask for your account password when creating a task. That is normal behaviour, not a sign of a problem. - A task set to run only while you are logged on does not run when you are not, which is the most common reason a nightly job never fires. On Linux or macOS the equivalent is a `cron` entry (`crontab -e`, and `crontab -l` to check). cron has no policy for overlapping runs, so the lock file the programs write to `state/` is the only thing preventing two runs at once there. 6. The optional live request ---------------------------- Nothing in this course requires one, and the course is complete without it. If you want to try a real request against a public service that needs no account, keep it bounded the way the course teaches: one request, a timeout, a request budget of one, and a recorded copy of the response saved to a file so every later run reads the recording instead of the service. Then delete the live call and keep the recording. That is the arrangement the whole services module describes, and doing it once by hand is what makes it stick. Do not put a credential in any of these files. The programs here have no place to put one, and none of them needs one.