On 2020-10-31 19:48:29 +0500 (+0500), Andrey Rahmatullin wrote: > On Sat, Oct 31, 2020 at 12:03:50PM +0100, Thomas Goirand wrote: > > Pypi is often thought as a Python module source repository. It > > is *NOT*. It is a repository for binaries to be consumed by pip. > > Oooh, that's a very interesting thought I never considered. It's not entirely accurate, however. These days there are two remaining package formats commonly distributed through PyPI: sdists and wheels. The sdist format is intended to be a platform-independent "source distribution" (hence its name), perhaps more analogous to Debian's own source package formats, and the traditional setup.py in many sdists is akin to debian/rules and the $PACKAGE.egg-info/ tree similar to other sorts of metadata you would expect under the debian/ directory. Python package installation tools like pip call libraries to do things like compile and link included C extensions from the unpacked sdist before installing the results into a usable location in the system (or more recently, putting the results into a wheel package, then caching that and installing its contents into the system). When it comes to "binaries" this is definitely the domain of wheels. A wheel is (usually, with the exception of toolchains like flit) built from an sdist and may be platform-dependent, especially if it contains compiled extensions. The wheel is much more akin to Debian's binary package format. The main operating system distribution package maintainer argument against relying on sdists is that they may omit files from the upstream revision control system which that upstream did not want included in their official source distributions, or may include extra generated files which upstream did want included but don't exist (or at least don't exist as files in that form) within the upstream revision control. This is perhaps not entirely dissimilar from C/autotools based projects having a `make dist` target which they use to prepare their source distribution tarballs. Whether it actually represents a problem for downstream packaging likely varies a bit from project to project. -- Jeremy Stanley
Attachment:
signature.asc
Description: PGP signature