agrim-p777/conda-package-genn

1. What this repository is

This repo is not the GeNN source code itself; it is the packaging and release architecture for distributing PyGeNN as Conda packages. The goal is to turn a source-built C++/CUDA scientific library into installable binaries for end users.

2. Two primary product lines

The architecture splits into two top-level package families:

- pygenn-cpu: CPU-only build, no CUDA dependency

- pygenn-cuda: GPU-enabled build, depends on CUDA toolchain/runtime packages

This is the main product boundary in the repo.

3. Conda recipe as the central build unit

Each package family is built from a Conda recipe centered on:

- meta.yaml for package metadata, dependency pins, outputs, and build commands

- conda_build_config.yaml for variant selection and version pinning

The recipes are the authoritative architecture layer; everything else supports them.

4. Build configuration is platform- and version-aware

The tree contains multiple recipe variants for Linux, Windows, and macOS, plus CUDA version splits such as CUDA 11.7 and CUDA 12.x / 12.4.

That indicates the repo is organized around a matrix of build targets, not a single universal build script.

5. CPU vs CUDA have different dependency boundaries

The CPU package is a simpler runtime distribution of the Python bindings plus the compiled GeNN backend libraries.

The CUDA package adds the full GPU compilation/runtime boundary: modular CUDA Conda packages, CUDA path handling, and post-install guidance.

This is the key architectural distinction between the two deliverables.

6. Post-install behavior is part of the package design

The CUDA recipe includes post-link.sh and post-link.bat, which means installation is not purely file copy based.

The package also needs to communicate runtime environment setup, especially CUDA_PATH, so install-time hooks are used as part of the user-facing architecture.

7. Platform-specific build adaptations

The presence of separate folders like pygenn-cpu (mac01), pygenn-cpu (mac02), pygenn-win-cpu, pygenn-win-cuda (nmake), and Linux-specific recipe dirs shows the project had to encode OS-specific build mechanics:

- macOS dynamic library handling

- Windows build-system differences, including NMake/MSBuild

- Linux recipes with simpler native toolchain assumptions

These are not just alternate configs; they represent distinct packaging solutions per platform.

8. Runtime artifact handling is important

The README highlights fixes for macOS .dylib packaging and Windows CUDA path resolution, which means the package boundary includes:

- compiled shared libraries

- Python extension/modules

- platform loader behavior

The repo therefore bridges Python packaging and native binary distribution.

9. Tests are smoke tests, not application tests

The tests/ directories contain smoke tests for both CPU and CUDA packages:

- run_pygenn_cpu_smoketest.py

- run_pygenn_cuda_smoketest.py

- test.py

These likely validate that the installed package can be imported and that the backend loads correctly in a Conda environment. The tests are aimed at packaging integrity rather than model correctness.

10. Conda-Forge publication pipeline is explicit

The Conda_Forge/ directory mirrors the package families, indicating a separate layout for Conda-Forge submission and CI-ready recipes.

This repo supports the path from local packaging work to staged/official Conda-Forge recipes, so the architecture includes a recipe authoring layer and a distribution layer.

11. Documentation and assets are supporting, not operational

README.md and the assets/ directory are documentation/branding support. They explain the packaging rationale, but they are not part of the build or runtime path.

12. Overall data flow

The high-level flow is:

GeNN source build inputs and platform toolchains → Conda recipe selection (meta.yaml + conda_build_config.yaml) → platform/CUDA-specific build → packaged Python bindings and native libraries → post-link environment guidance → smoke tests in Conda environments.

That is the architectural story this repo encodes.