What is a binary package for a pure-Python library?

Packaging
,
1

pip install --no-binary :all: --no-cache will download tarballs, .gz files, build and install.

pip install --no-binary :all: will happily reuse locally built wheel.

At the same time PEP 425 – Compatibility Tags for Built Distributions | peps.python.org mentions

for example, a user might accept only the *-none-any tags to only download built packages that advertise themselves as being pure Python.

My case is a pure python package and we publish both wheels and tarballs, here’s the local build:

> ls dist/
ops-2.16.0.dev0-py3-none-any.whl  ops-2.16.0.dev0.tar.gz

I guess there’s some logic to current behavour, but can I rely on it?
Is it formally specified?

Could it be that --no-binary flag is slightly misnamed and --no-built would be better?

2

I believe this is pip specific terminology and pip specific CLI options (though other tools do copy pip’s interface).

So I think it would best be discussed on the pip GitHub issue page.

And while I do agree that no-binary and only-binary do occasionally cause confusion, the difference here is wheels vs sdists, not about whether a package is pure Python or not, and pip needs very good reason to make any breaking changes as it’s such a critically relied on tool.

4 Likes
3

I think you can rely on --no-binary not downloading wheels. As you mentioned, ‘binary’ here means ‘built’, and in practice means wheels, as pip never supported any of the other built package formats, and there’s not much reason to add support now.

I’d guess that what is cached and when it is used is an implementation detail of pip, so you shouldn’t rely on it reusing locally built wheels.

2 Likes