setuptools

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

sult, I use setuptools only. `setuptools` has the advantage of preferential treatment within the ecosystem (e.g., at least transitionally, a `[build-system]` table like the one shown could be omitted completely, as Setuptools would be assumed by default; and virtual environments used to bootstrap Setuptools as well as Pip by default. However, with current versions of Pip (and Python, thus venv from the standard library), as well as with `build`, the default behaviour is to create an "isolated environment" for building (even, AFAIK, if the project is already containerized - how would the tools know, after all?). This entails creating a new venv and installing Setuptools therein - using Pip to find the latest version (subject to any version constraints specified in pyproject.toml) on PyPI. In theory, packages that Pip downloads from PyPI are cached; but even when Setuptools hasn't released a new version since the last build, any number of things could defeat that caching scheme. This is important because, while Setuptools works and it succeeds in making the simple cases simple (including with the new pyproject.toml-powered approach), it's a massive boat-anchor for most projects that use it. The wheel size approaches 1MB for a possibly-transient download used just to "build" your project - which in most cases doesn't even involve a compilation step (actually telling Setuptools to run compilers requires a separate setup.py file, even with pyproject.toml) but just moves some files around and creates a zip archive - and which in most cases is itself quite a bit smaller. It got to this size, effectively, by starting its life as a decades-old attempt at a full project management toolchain, and then collapsing under the weight of deprecations and backwards-compatibility hacks (including, now, the need to vendor `distutils` since that was removed from the standard library in 3.12). Notably, originally setup.py was intended to be run directly chosen by the user, but now Setuptools does magic to spawn a new process (IIRC), run it with very specific arguments and collect the results somehow. Meanwhile, even the most conservative attempts to remove old deprecated functionality (such as the ability to run `setup.py test` manually, even though it has nothing to do with the modern Setuptools workflow and everyone uses Pytest and invokes that directly nowadays) have caused huge breakages in the ecosystem and embarrassing rollbacks (see https://github.com/pypa/setuptools/issues/4519 as a starting point), even for pure-Python projects where that functionality was grossly unnecessary and wasn't actually being used (notably: Requests - https://github.com/psf/requests/issues/6775 - and Celery - https://github.com/celery/celery/issues/9157 ). Setuptools is one of the most popular packages on PyPI. I estimate, based on the available public data, that it accounts for about 1% of all PyPI download bandwidth - petabytes per year, worth perhaps a dev's entire salary at market rates. I suspect that a very high fraction of these downloads should be unnecessary if people were properly educated about how this works - and even where Setuptools is used, it could be much smaller while providing the same non-deprecated functionality - and most users aren't using most of that functionality anyway. I have much more to say about this, as part of a broader discussion of Python wheel sizes. I'm hoping I can get to that blogpost within the next month or so. In the mean time: I have been working on a build backend called `bbbb` that attempts to be minimal. It's not at all production-ready yet, but you can get a basic sense of what I'm going for: https://github.com/zahlman/bbbb/ . It's at least powerful enough to package itself, and should work for any project that's only Python code aside from its dependencies, if you use src layout and are careful about file placement. If you need something that's properly tested and such, now, I recommend Flit. It doesn't, by design, provide a way to deal with compiled extensions (whereas I will eventually), and it's definitely not as small as it could be (it vendors `tomli` and includes its tests in the wheel, which you'll never have a reason to run yourself) - but it's still much smaller than Setuptools.