sigstore-python VS auditwheel

You could use `pip-compile` if you want full pinning. That's what we do on another project -- we use GitHub Actions with `pip-compile` to provide a fully frozen copy of the dependency tree for users who'd like that[1].

In the context of `pip-audit`, that makes a little less sense: most of our dependencies are semantically versioned, and we'd rather users receive patches and fixes to our subdependencies automatically, rather than having to wait for us to release a corresponding fix version. Similarly, we expect users to install `pip-audit` into pre-existing virtual environments, meaning that excessive pinning will produce overly conservative dependency conflict errors.

[1]: https://github.com/sigstore/sigstore-python/tree/main/instal...

The conflicting advice is a serious problem.

I hope you'll forgive me for adding one additional piece of advice: for many Python packages, the only packaging metadata you need is `pyproject.toml`. You don't even need `setup.py` anymore, so long as you're using a build backend that supports editable installs with `pyproject.toml`.

Here's an example of a Python package that does everything in `pyproject.toml`[1]. You should be able to copy that into any of your projects, edit it to match your metadata, and everything will work exactly as if you have a `setup.cfg` or `setup.py`.

[1]: https://github.com/sigstore/sigstore-python

You're right, both the infrastructure and metadata for cryptographic signatures on Python packages (both wheels and sdists) isn't quite there yet.

At the moment, we're working towards the "e2e" scheme you've described by adding support for Sigstore[1] certificates and signatures, which will allow any number of identities (including email addresses and individual GitHub release workflows) to sign for packages. The integrity/availability of those signing artifacts will in turn be enforced through TUF, like you mentioned.

You can follow some of the related Sigstore-in-Python work here[2], and the ongoing Warehouse (PyPI) TUF work here[3]. We're also working on adding OpenID Connect token consumption[4] to Warehouse itself, meaning that you'll be able to bootstrap from a trusted GitHub workflow to a PyPI release token without needing to share any secrets.

[1]: https://www.sigstore.dev/

[2]: https://github.com/sigstore/sigstore-python

[3]: https://github.com/pypa/warehouse/pull/10870

[4]: https://github.com/pypa/warehouse/pull/11272

Hi there! I've recently spent a lot of time figuring out how to distribute tools written in Python as standalone, self-contained executables, that will works on most of the linux distribution without special environment (including python itself). Decided to write this post to share and discuss my approach. I'd be grateful for any feedback and help on that topic! Here are a few simple steps I've come up with to make this trick: 1) This first is very obvious - use special tooling that can make such an executable, like Nuitka, Pyoxidizer, PyInstaller, python-appimage, etc. 2) Build your application against old enough glibc. You can do this using some old Linux distribution or just be setting up such toolchain manually. Its matters for c extensions, tools like nuitka/pyoxidizer and the python itself. 3) Last but not least - don't forget about dependencies and the dependencies of your dependencies. All Python wheels should have either an `any` [platform tag](https://packaging.python.org/en/latest/specifications/platform-compatibility-tags/) or one of the [manylinux](https://peps.python.org/pep-0600/) tags that suits your requirements. You can check tags and repair the bad ones with [auditwheel](https://github.com/pypa/auditwheel). But fortunately, in the last 5-10 years, most of the mainstream packages have received manylinux wheels. Of course, there will be issues with PyOxidizer/Nuitka/pyinstaller/etc pitfalls, especially with big projects, so you need some e2e tests in every Linux you want to support. For educational purposes, I made [this little repo](https://github.com/asapelkin/overpackaged). It includes: 1) A sample app with bad dependencies and a C extension. 2) A script to create a 'wheelhouse' with compatible wheels only (`manylinux*` and `any`). 3) Scripts to build executables using Nuitka, PyOxidizer, Appimage, pex. 4) Portability tests (run executables in different linux distros) and performance benchmarks. 5) Readme and Makefile to run any step with single command. It's obviously not a very useful repo, but at least it helped me to explore this topic a little, maybe it could help to demonstrate my approach to the topic.

In a similar vein: Python projects can use `auditwheel` to automatically relocate (fixup RPATHs) and vendor their "system" dependencies, such as a specific version of `zlib` or `libffi`[1].

[1]: https://github.com/pypa/auditwheel

I was using manylinux as it was suggested by its example and it gathered the libraries via auditwheel and included them into the package. Up to my knowledge, there is no way to exclude libraries from the package, because it cannot have external dependencies apart from the predefined list of libraries. The linux_*.whl tags cannot be used on PyPI for binary packages.