Comment by westurner

I decided to look into how this works these days.

These days you need toml to parse pyproject.toml, and there's not a parser in the Python standard library for TOML: https://packaging.python.org/en/latest/guides/writing-pyproj...

pip's docs strongly prefer project.toml: https://pip.pypa.io/en/stable/reference/build-system/pyproje...

Over setup.py's setup(,setup_requires=[], install_requires=[]) https://pip.pypa.io/en/stable/reference/build-system/setup-p...

Blaze and Bazel have Skylark/Starlark to support procedural build configuration with maintainable conditionals

Bazel docs > Starlark > Differences with Python: https://bazel.build/rules/language

cibuildwheel: https://github.com/pypa/cibuildwheel ;

> Builds manylinux, musllinux, macOS 10.9+ (10.13+ for Python 3.12+), and Windows wheels for CPython and PyPy;

manylinux used to specify a minimum libc version for each build tag like manylinux2 or manylinux2014; pypa/manylinux: https://github.com/pypa/manylinux#manylinux

A manylinux_x_y wheel requires glibc>=x.y. A musllinux_x_y wheel requires musl libc>=x.y; per PEP 600: https://github.com/mayeut/pep600_compliance#distro-compatibi...

> Works on GitHub Actions, Azure Pipelines, Travis CI, AppVeyor, CircleCI, GitLab CI, and Cirrus CI;

Further software supply chain security controls: SLSA.dev provenance, Sigstore, and the new PyPI attestations storage too

> Bundles shared library dependencies on Linux and macOS through `auditwheel` and `delocate`

delvewheel (Windows) is similar to auditwheel (Linux) and delocate (Mac) in that it copies DLL files into the wheel: https://github.com/adang1345/delvewheel

> Runs your library's tests against the wheel-installed version of your library

Conda runs tests of installed packages;

Conda docs > Defining metadata (meta.yaml) https://docs.conda.io/projects/conda-build/en/latest/resourc... :

> If this section exists or if there is a `run_test.[py,pl,sh,bat,r]` file in the recipe, the package is installed into a test environment after the build is finished and the tests are run there.

Things that support conda meta.yml declarative package metadata: conda and anaconda, mamba and mambaforge, picomamba and emscripten-forge, pixi / uv, repo2docker REES, and probably repo2jupyterlite (because jupyterlite's jupyterlite-xeus docs mention mamba but not yet picomamba) https://jupyterlite.readthedocs.io/en/latest/howto/configure...

The `setup.py test` command has been removed: https://github.com/pypa/setuptools/issues/1684

`pip install -e .[tests]` expects extras_require['tests'] to include the same packages as the tests_require argument to setup.py: https://github.com/pypa/setuptools/issues/267

TODO: is there a new one command to run tests like `setup.py test`?

`make test` works with my editor. A devcontainers.json can reference a Dockerfile that runs something like this:

  python -m ensurepip && python -m pip install -U pip setuptools

But then still I want to run the tests of the software with one command.

Are you telling me there's a way to do an HTTPS Content Range request for the toml file in a wheel for the package dependency version constraints and/or package hashes (but not GPG pubkey fingerprints to match .asc manifest signature) and the build & test commands, but you still need an additional file in addition to the TOML syntax pyproject.toml like Pipfile.lock or poetry.lock to store the hashes for each ~bdist wheel on each platform, though there's now a -c / PIP_CONSTRAINT option to specify an additional requirements.txt but that doesn't solve for windows or mac only requirements in a declarative requirements.txt? https://pip.pypa.io/en/stable/user_guide/#constraints-files

conda supports putting `[win]` at the end of a YAML list item if it's for windows only.

Re: optimizing builds for conda-forge (and PyPI (though PyPI doesn't build packages (when there's a new PR, and then sign each build for each platform))) https://news.ycombinator.com/item?id=41306658