Skip to content

Commit 04bf1bb

Browse files
committed
Partially flesh out "Publishing binary extensions" section
This converts the items from the existing FIXME that are still relevant while fleshing out the topic of binary-only releases.
1 parent b18fd61 commit 04bf1bb

File tree

1 file changed

+14
-10
lines changed

1 file changed

+14
-10
lines changed

source/guides/packaging-binary-extensions.rst

Lines changed: 14 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -356,20 +356,24 @@ Spinning Wheels wiki
356356
Publishing binary extensions
357357
============================
358358

359-
For interim guidance on this topic, see the discussion in
360-
:issue:`this issue <284>`.
359+
Publishing binary extensions through PyPI uses the same upload mechanisms as
360+
publishing pure Python packages. You build a wheel file for your extension
361+
using the build-backend and upload it to PyPI using
362+
`twine <https://twine.readthedocs.io/>`_.
361363

362-
..
364+
Avoid binary-only releases
365+
--------------------------
363366

364-
FIXME
367+
It is strongly recommended that you publish your binary extensions as
368+
well as the source code that was used to build them. This allows users to
369+
build the extension from source if they need to. Notably, this is required
370+
for certain Linux distributions that build from source within their
371+
own build systems for the distro package repositories.
365372

366-
* cover publishing as wheel files on PyPI or a custom index server
367-
* cover creation of Windows and macOS installers
368-
* cover weak linking
369-
* mention the fact that Linux distros have a requirement to build from
370-
source in their own build systems, so binary-only releases are strongly
371-
discouraged
373+
Weak linking
374+
------------
372375

376+
FIXME: This section needs to be fleshed out.
373377

374378
Additional resources
375379
====================

0 commit comments

Comments
 (0)