# Planning Meeting: Build Systems, CI Infrastructure
**Date:** Friday 12:00 - 1:00 PM
**Topics:** Build Systems, CI Infrastructure
**Issues:** [#3](https://github.com/scientific-python/summit-2023/issues/3), [#5](https://github.com/scientific-python/summit-2023/issues/5)

### Attendees
- Juanita Gomez
- Brigitta Sipőcz
- Jarrod Millman
- Stéfan van der Walt
- Leah Wasser
- Martin Fleischmann
- Paul Ivanov
- Tyler Reddy
- Henry Schreiner
- Mridul Seth
- Levi Wolf
- Madicken Munk
- Greg Lee

## Relevant links

- https://scientific-python.org/specs/spec-0004/
- https://scientific-python.org/specs/spec-0005/

## Ideas from issues

**Brigitta**:

- job that tests nightly wheels/dev versions. Maybe a separate job that tests pre-releases.
- job that tests the oldest supported versions of declared dependencies
- cron jobs: notification are not working properly on github, we should implement a small tool, workaround to get notifications to maintainers
- filterwarnings to error out on warnings: expected warnings should be handled in CI, or ignored. Erroring out by default provides enormous help to notice new deprecations while upstream dependencies are still in their dev cycle (assuming there is a job that uses the dev versions/nightly builds)

Also, this could include documentation about the available CI tooling, though there is a risk involved here with keeping this up-to-date.

**Dan McCloy**: encouragement / guidance / templates for member projects on setting up a CI job that uses pip --pre or nightlies or some other way of getting early warning of breaking changes in dependencies. This could involve tutorial/documentation material (#21) as well as template files (#10)

**Brigitta:** another piece: cron github jobs to issue send out notifications (preferably staying within github rather than an email, but email is still better than the current not really predictable mess). Of course, it would be best if github would start supporting it, but I don't think we should wait for them as it could take years.

Chatted with Ross about this, but haven't come up with an actual implementation to make it happen.

-------------------------------------------------------

## Meeting notes

Jarrod: two issues, not sure which one to start with.
- let's start with build system stuff.
- working with networkX - not a lot of building difficulties there
- CIbuildwheel system

Henry:
- [scikit-build / scikit-build-core](https://github.com/scikit-build/scikit-build-core), [meson / meson-python](https://meson-python.readthedocs.io/en/latest/) avoid setuptools
- question: what do we want to address - there are lots of things that would be needed.
- scikit-HEP development pages
- reporeview.dev?
- cookie-cutter that has 12 different backends
- put it under a better name?
Jarrod:
- most projects are aware of 3.12 coming out
- 3.12 removes distutils, but doesn't affect all that many projects
- Except those based on numpy.distutils?
- But, in next beta (on Monday, 5/22), setuptools no longer in default environment; so libraries won't build without `pyproject.toml`
- ~300 projects using scikit-build, 80 did not have a pyproject.toml

Leah:
- people are confused about which project they should be using to get started
- what are the general standards that work for people that are not using pure python
* sounds like there is some examples in scikit build docs for fortran??

Henry:
- https://scikit-build-core.readthedocs.io/en/latest/getting_started.html
- there needs to be better documentation on examples showing multiple systems

Jarrod:
- there may be some churn, like there was with version control

Henry:
- CMake is heavily used. Building subproject while building a project.

Leah:
- Sometimes options are overwhelming, and some people just want an answer.

Ross:
- as someone that wants to just be a consumer of this
- PyPA's distributing binary extension is "FIXME" and has been, for years
- https://packaging.python.org/en/latest/guides/packaging-binary-extensions/#publishing-binary-extensions

Jarrod https://github.com/scientific-python/spin
- common interface to build docs, run test
- currently works with meson-python
- extension of devpy

Henry:
- why not use tox and nox?

Example from Stéfan - https://github.com/scikit-image/scikit-image/blob/main/.spin/cmds.py

Henry:
- I think a large part of the reason dev.py got developed is there was no editable install at the time.

Ross:
- `pip install -e .` and `make html` used to work on all of the projects

Henry:
- standardization could be a set of commands that all projects support.

## CI discussion
Brigitta:
- two draft SPECs to push over the draft status

GH actions

# Action Plan

- review/compare/unify spin/nox/tox
- S: can we get nox to print a proper help string? E.g.:

$ spin docs --help
Usage: spin docs [OPTIONS]

  📖 Build documentation

  By default, SPHINXOPTS="-W", raising errors on warnings. To build without raising on warnings:

    SPHINXOPTS="" spin docs

Options:
  --clean                             Clean previously built docs before building
  --install-deps / --no-install-deps  Install dependencies before building  [default: install-deps]
  --build / --no-build                Build skimage before generating docs  [default: build]
  --help                              Show this message and exit.

That would get us 80% of the way there.

- create a place where we collect topics to learn about
- port scikit-hep developer docs and use for training at summit
- finish/implement [SPEC 4 (nightly wheels)](https://specs.scientific-python.org/spec-0004/) and [SPEC 5 (CI best practices)](https://specs.scientific-python.org/spec-0005/), and [issue #3](https://github.com/scientific-python/summit-2023/issues/3)
- leah - id love to work a bit on suggestions / examples for non pure python packaging
- build pygrapviz wheels (Ross has SDist that can be installed but is struggling with packaging the required deps into the wheels)