Use venv/bin/python app.py to run it.

- name: fetch code
  uses: actions/checkout@v4

- uses: actions/setup-python@v5
  with:
    allow-prereleases: true
    python-version: |
      3.13
      3.12
      3.11
      3.10
      3.9
      3.8
      3.7

- run: pipx install nox

- name: run ward tests in nox environment
  run: nox -s test test_without_toml combine_coverage --force-color
  env:
    PYTHONIOENCODING: utf-8

- name: upload coverage data
  uses: codecov/codecov-action@v4
  with:
    files: ./coverage.json
    token: ${{ secrets.CODECOV_TOKEN }}

[tool.taskipy.tasks]
fmt = "nox -s fmt"
lock = "nox -s lock"
test = "nox -s test test_without_toml typecheck -p 3.12"
docs = "nox -s render_readme render_api_docs"

.ONESHELL:
.DEFAULT_GOAL := help
SHELL := /bin/bash
APP_NAME := logging_strict

#virtual environment. If 0 issue warning
#Not activated:0
#activated: 1
ifeq ($(VIRTUAL_ENV),)
$(warning virtualenv not activated)
is_venv =
else
is_venv = 1
VENV_BIN := $(VIRTUAL_ENV)/bin
VENV_BIN_PYTHON := python3
PY_X_Y := $(shell $(VENV_BIN_PYTHON) -c 'import platform; t_ver = platform.python_version_tuple(); print(".".join(t_ver[:2]));')
endif

.PHONY: mypy
mypy:					## Static type checker (in strict mode)
ifeq ($(is_venv),1)
	@$(VENV_BIN_PYTHON) -m mypy -p $(APP_NAME)
endif

import nox
from nox.sessions import Session

nox.options.reuse_existing_virtualenvs = True
APP_NAME = 'logging_strict'

@nox.session(python='3.12')
def mypy(session: Session):
    """Static type checker (in strict mode)"""
    session.install('-U', 'mypy', '.')
    session.run('mypy',  '-p', APP_NAME, *session.posargs)

Does it need access to anything local? If not, you could run it as an AWS Lambda on a schedule.

You could package it and install with pipx

I use pipenv with pyenv together. This works pretty well, also in cron jobs. Just add pipenv run python script.py to the cron table.

Just in case this comment didn’t make it explicitly clear, you can just invoke the python binary inside your venv directly and it will automatically locate all the libraries that are installed in your virtual environment.

To show how this works, you can look at the sys.path variable to see which paths python will search for modules when you run import statements. Try running python3 -c ‘import sys; print(sys.path)’ using your system python, and you will only see system python library paths. Then, try running it again after replacing python3 with the full path to the python3 binary in your venv, and you will see an additional entry in the output with the lib directory in your venv, which shows that python will also look there for modules when an import statement is executed.

As someone’s new comments just brought me back to this post, I’ll point out that these days there’s another good option: uv run.