Development Environment

pip install <WINCCOA_ROOT>\api.python\packages\etm_wccoa-<version>-py3-none-any.whl
pip install <WINCCOA_ROOT>\api.python\packages\etm_wccoa_manager-<version>-py3-none-any.whl

This works without any further infrastructure, but it ties the repository to a local installation.

Upload the wheels to the package index of your organization — for example Artifactory, Nexus or Azure Artifacts — and depend on them by name and version:

etm-wccoa==<version>
etm-wccoa-manager==<version>

Configure the index in pip.conf or pip.ini, or pass it with --index-url. This keeps the repository free of binary artifacts and lets several applications share the same API version.

If no package index is available, commit the wheels to the repository, for example to a vendor/ directory, and reference them from requirements.txt:

./vendor/etm_wccoa-<version>-py3-none-any.whl
./vendor/etm_wccoa_manager-<version>-py3-none-any.whl

pip install -r requirements.txt

The build node then needs nothing but CPython and the repository.

With either variant, keep the wheel version in sync with the WinCC OA version of the target system.

Leaving the API packages out allows the same artifact to run on any WinCC OA installation of the matching version.

PMON puts the python/libs/ directory at every level of the project search path on the PYTHONPATH of the manager process. That is where third-party packages belong on the target system.

Build that layout on the build node:

pip install -r requirements.txt --target dist/python/libs
Copy-Item src/*.py dist/python/

The result mirrors the structure of the project:

dist/
└── python/
    ├── my_script.py
    └── libs/
        └── <third-party packages>

pip resolves wheels for the platform and CPython version of the machine it runs on. If a dependency contains native code — numpy for example — build the artifact on a machine that matches the target system, or pass --platform, --python-version and --only-binary=:all: to pip. Pure Python dependencies are not affected.

The layout above shares one directory with every other Python manager on the target system. Install into dist/python/<application>/libs instead if the application is to keep its dependencies to itself, as described in Several Applications on One System.

Whichever channel you use, publish the tree above as one versioned unit and record the WinCC OA version it was built against.

1. Install WinCC OA including PythonEnv, and CPython. This is done once per system, not once per application.
2. Unpack the artifact so that the scripts end up in <project>/python/ and the dependencies in <project>/python/libs/. A subproject is an alternative target that keeps the application separate from the project configuration.
3. Add the manager in the Console, as described in Getting Started.
4. Restart the manager to activate new code.

A virtual environment is the natural choice on the workstation and on the build node. On the target system, it needs more thought.

PMON starts the first python executable it finds in a bin/ directory of the project search path and otherwise leaves the lookup to the operating system. It then sets PYTHONPATH and WCCOA_BIN_DIRS for the manager process. It does not activate a virtual environment.

A virtual environment, therefore, only takes effect if the interpreter that PMON starts belongs to it, which means the environment has to be active for the process monitor itself. Deploying the dependencies to <project>/python/libs/ avoids that dependency on the process environment, which is why it is the approach described above.

Each Python manager runs as its own operating system process. Two managers can therefore use different versions of the same package at runtime without interfering with each other. What they share is the search path: PMON adds the same python/libs/ directories to the PYTHONPATH of every Python manager. A package that exists there is available in exactly one version for all of them.

This matters as soon as applications with independent release cycles run on the same system. Subprojects do not solve it, because their python/libs/ directory is on the search path of every manager as well and it only changes the order in which packages are found.

Give each application a directory of its own below python/ and keep its dependencies inside it:

<project>/python/
├── plant_monitor/
│   ├── main.py
│   ├── monitoring.py
│   └── libs/
│       └── <dependencies of plant_monitor>
└── report_export/
    ├── main.py
    └── libs/
        └── <dependencies of report_export>

Enter the script as plant_monitor/main.py in the Console. PMON resolves the path below the python/ directory of every level of the project search path.

CPython puts the directory of the started script at the front of sys.path, so the modules next to main.py are importable without further setup. The dependencies require one line at the top of the entry script:

import os
import sys

sys.path.insert(0, os.path.join(os.path.dirname(__file__), "libs"))

from etm.wccoa.manager import Manager  # noqa: E402

Keep this line in the entry script only, never in a module, and place it before the first import of a third-party package so that the entries provided by PMON are consulted afterwards. The WinCC OA packages come from the installation and are the same for every manager; importing them after this line is intentional.

Because the directory of the application is the first entry of sys.path, a module named like one of the standard library — logging.py or queue.py for example — hides the standard module from the whole process. Choose names that cannot collide.

Use python/libs/ for packages that all applications on the system share and the libs/ directory of an application for everything with its own release cycle.