pip-audit

This is a great summary, although I think I'm more bearish on SBOMs than Andrew is: my experience integrating them so far (in both pip-audit and uv) has been that there's much more malleability at the representation level than the presence of a standard might imply, and that consumers have adapted (a la Postel) to this reality by being very permissive with the kinds of broken stuff they permit when ingesting third-party SBOMs. (Case in point: pip-audit's CycloneDX emission was subtly incorrect for years, and nobody noticed[1].) [1]: https://github.com/pypa/pip-audit/pull/981

Here is my "one true" Makefile for Python projects[1]. The skeleton gets tweaked slightly each time, but it's served me well for 4+ years. [1]: https://github.com/pypa/pip-audit/blob/main/Makefile

in the name of supply chain security, i just want verified package signatures (cosign, not the extant unused gpg), the new passwordless publication is good step towards (get humans and static credentials out of pushing assets). actually one more minor, support for poetry in pip-audit.. https://github.com/pypa/pip-audit/issues/84

It's not very well documented, but the PyPA tools do provide a unified experience when used correctly. Here's a PyPA project (FD: one I work on) that uses a single pyproject.toml to handle all aspects of packaging (and most non-packaging tool configuration, to boot)[1]. With a single file like that, the only thing you need to do to start a local development environment is: python -m venv env && . env/bin/activate python -m pip install .[dev] (We provide a `make dev` target that does that for you as well.) Similarly, to build distributions, all you need is `build`: python -m build [1]: https://github.com/pypa/pip-audit

If it's pure Python, the only packaging file you need is `pyproject.toml`. You can fill that file with packaging metadata per PEP 518 and PEP 621, including using modern build tooling like flit[1] for the build backend and build[2] for the frontend. With that, you entire package build (for all distribution types) should be reducible to `python -m build`. Here's an example of a full project doing everything with just `pyproject.toml`[3] (FD: my project). [1]: https://github.com/pypa/flit [2]: https://github.com/pypa/build [3]: https://github.com/pypa/pip-audit

This is really nicely written; kudos to the author for compiling a great deal of information in a readable format. If I can be forgiven one nitpick: Poetry does not use a PEP 518-style[1] build configuration by default, which means that its use of `pyproject.toml` is slightly out of pace with the rest of the Python packaging ecosystem. That isn't to say that it isn't excellent, because it is! But you the standards have come a long way, and you can now use `pyproject.toml` with any build backend as long as you use the standard metadata. By way of example, here's a project that's completely PEP 517 and PEP 518 compatible without needing a setup.py or setup.cfg[2]. Everything goes through pyproject.toml. [1]: https://peps.python.org/pep-0518/ [2]: https://github.com/trailofbits/pip-audit/blob/main/pyproject...

Since this is about Python specifically, I'll go ahead and and highlight `pip-audit`[1] as a specialized tool for generating Python SBOMs and running audits against the official PyPI vulnerability feed. FD: My company, my work. [1]: https://github.com/trailofbits/pip-audit

Hooray! Loosely related - This is Python pip. Trail of Bits has a tool pip-audit that audits Python environments and dependency trees for known vulnerabilities. https://github.com/trailofbits/pip-audit

This is why I stuff everything into a top-level Makefile with `.PHONY` rules instead. Nearly every developer knows how to invoke `make` and already has tab completion for `make` rules, to boot. The CI in turn calls `make` as well, so there's no duplication. For example: https://github.com/trailofbits/pip-audit/blob/main/Makefile

It’s not ready for showtime yet, but this is being worked on[1]. [1]: https://github.com/trailofbits/pip-audit