MetOffice / MetOffice/CMEW

Create a `cmewpy` Python package

Open
#511 0 comments 0 reactions 1 assignee Claimed by @ehogan View on GitHub
quality assurance technical debt testing
Dominant language
Python
Stars
5
Forks
3
Avg merge
5d 6h
Merged PRs (30d)
8

Description

I started work on #321 and discovered that I could not run `pytest` on the command line.

I noticed this comment from about one month ago: https://github.com/MetOffice/CMEW/issues/274#issuecomment-4668846934:

> Currently I am having to add the `CMEW/lib/python` directory to my `PYTHONPATH` to run `pytest` locally (this is automatically added in a Cylc run). I'm not sure if this is acceptable, or what a better work-around or solution might be.

Ideally `pytest` would "just work" on the command line, without needing to do anything.

There is already an issue open related to restructuring test files: #228.

I did try a few things (including using [--import-mode=importlib](https://github.com/ESMValGroup/ESMValTool/issues/3670#issuecomment-2181336086), but I feel the best solution is to:

- create a directory within CMEW that contains all the Python code and tests (a `cmewpy` Python package)
- copy all Python code into the workflow at install time (into `share/lib/python/`, as detailed at [Cylc documentation: Workflow Share Directories](https://cylc.github.io/cylc-doc/stable/html/user-guide/writing-workflows/runtime.html#workflow-share-directories)

This should allow `pytest` to be run on the command line, as well as via the `unittest` task via CMEW (and ultimately via a GitHub workflow). The `pyproject.toml` file can be moved into the Python package. The top level structure might look something like:

```
CMEW
CMEW
cmewpy
pyproject.toml
cmewpy

tests

```

Questions:

- What would be the preferred way to structure the Python modules?
1:
```
cmewpy
configure_standardise
create_request_file.py
create_variables_file.py
```
2:
```
cmewpy
configure_standardise.py (contains `create request file` and `create variables_file` functions)
```
3: Something else?
- Should #318 be agreed on before starting this restructure?

Answers (agreed at the ad-hoc technical meeting on Mon, Jul 6, 2026):

- Option 1 was the preferred options.
- We agreed to use the current naming and deal with the rename of everything separately via #318

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.