Packaging Requirements

1. surmise developers shall be allowed to include .c files in the package including the possibility that some .c files be generated automatically by Cython from developer created and managed .pyx files.

2. All .c files shall be included in the version control repository and in source distributions of the package. In accord with Cython and setuptools suggestions, this requirement includes .c files generated automatically by Cython from .pyx case. In such cases, the .pyx file shall also be included in the version control repository alongside the associated .c files and distributed as well.

3. If surmise does include .c files, then the developers shall build, test, and distribute via PyPI prebuilt binary wheels for current versions of Python for use with macOS (Intel and ARM64 processors), Linux, and Windows (via Ubuntu). The source distribution shall also be distributed via PyPI so that users with a system not compatible with a prebuilt binary wheel can still build and install surmise. A procedure shall be provided in a high-level README to aid building and installing the package manually from source. If no .c files are used, the package shall be distributed via PyPI as a source distribution and a universal Python wheel.

4. To adhere to PEP518, the package shall include a pyproject.toml file that specifies the build system environment at the very least. If the repository uses Cython, then a setup.py file will be used as suggested by Cython to manage the inclusion of the associated C code as setuptools extensions. In such a case, the package design shall endeavor to decouple pyproject.toml and setup.py as much as possible by including in the former only those specifications needed to build and distribute the package (e.g., the build system environment specification, automatic version determination needed before building via setuptools-scm, building/testing prebuilt binary wheels via cibuildwheel).

5. If .c files use numpy, then the package shall be designed so that developers are responsible for determining what single version of Cython all developers must use to generate .c files in the repository (if any) and what single version of the numpy is used both as a target for generation of any .c files from .pyx files that use numpy as well as for linking the compiled C code to numpy. The numpy version shall be specified as the sole acceptable version of the numpy build requirement in the build system environment specification in pyproject.toml. The determination of numpy version for compilation as well as for installation shall be made so that the numpy version installed by users is compatible with the numpy version used to compile code. The set of numpy versions allowed at installation shall be specified in setup.py as usual. At the time of writing this requirement, for example, this means that the numpy version used at build time must be from v2 so that it is compatible with all allowed v2.X installations as well as all compatible v1.Y versions.

6. The repository infrastructure shall include testing that verifies that surmise packages built with the fixed build-time numpy version are compatible with the latest v2 numpy version as well as the oldest v1.Y version supported by surmise as expressed in setup.py. If possible, tools such as dependabot shall be incorporated so that such tests are run every time a new numpy version is released. This requirement is in accord with numpy suggestions.