APKBUILD examples:Python: Difference between revisions
(Python 3 should be really preferred and Python 2 used only when needed) |
(gpep517 only) |
||
(24 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
A lot of Python packages use the ''setuptools'' or ''distutils'' framework. This mean that the build() and the package() section looks a bit different compared to an application which uses ''make''. | A lot of Python packages use the ''setuptools'' or ''distutils'' framework. This mean that the build() and the package() section looks a bit different compared to an application which uses ''make''. | ||
== Considerations == | == Considerations == | ||
=== pkgname === | === pkgname === | ||
Package name for a Python ''library'' must be prefixed with | Package name for a Python ''library'' must be prefixed with ''py3-''. | ||
For an 'executable' (for example, <code>black</code>, <code>binwalk</code>), you generally don't need to prefix it. | |||
There’s no exact rule if the prefix should be used for tools and applications written in Python, it varies. | There’s no exact rule if the prefix should be used for tools and applications written in Python, it varies. | ||
Line 23: | Line 13: | ||
=== arch === | === arch === | ||
; noarch : Use for pure Python packages (i.e. without compiled code) | ; noarch : Use for pure Python packages (i.e. without compiled code). | ||
; all (and others) : Use for packages with native extensions (i.e. with compiled code). '''Do not''' add | ; all (and others) : Use for packages with native extensions (i.e. with compiled code). '''Do not''' add python3 to <tt>depends=</tt> (it's auto-detected via dynamic linking to python library). | ||
=== source === | === source === | ||
Most Python packages are published in [https://pypi.python.org/pypi PyPI](the Python Package Index). | |||
If the package has a source tarball available in PyPI (that’s true for most packages), you should reference it in <tt>source=</tt> as: | If the package has a source tarball available in PyPI (that’s true for most packages), and it contains tests (some explicitly remove them from PyPI), you should reference it in <tt>source=</tt> as: | ||
<pre> | <pre> | ||
https://files.pythonhosted.org/packages/source/${ | https://files.pythonhosted.org/packages/source/${_pyname%${_pyname#?}}/$_pyname/$_pyname-$pkgver.tar.gz | ||
</pre> | </pre> | ||
where <tt> | where <tt>_pyname</tt> is the real name of the Python package. | ||
Otherwise, use the normal upstream git tarballs. | |||
== Examples == | == Examples == | ||
=== pep517 invocation === | |||
=== | |||
<pre> | <pre> | ||
pkgname="py3-foo" | pkgname="py3-foo" | ||
... | ... | ||
depends=" | depends="py3-bar py3-baz" | ||
makedepends=" | makedepends="py3-gpep517 py3-setuptools py3-wheel python3-dev" | ||
subpackages=" | checkdepends="py3-pytest" | ||
subpackages="$pkgname-pyc" | |||
... | ... | ||
build() { | build() { | ||
gpep517 build-wheel \ | |||
--wheel-dir dist \ | |||
--output-fd 3 3>&1 >&2 | |||
} | } | ||
check() { | check() { | ||
python3 -m venv --clear --system-site-packages testenv | |||
testenv/bin/python3 -m installer dist/*.whl | |||
python3 | testenv/bin/python3 -m pytest | ||
} | } | ||
package() { | package() { | ||
python3 -m installer -d "$pkgdir" \ | |||
dist/*.whl | |||
} | } | ||
</pre> | </pre> | ||
Depending on the <code>build-backend</code> in the pyproject.toml, you might need py3-setuptools or py3-flit-core or py3-poetry-core or py3-hatchling at build time. If a project specifies literally <code>flit</code> or <code>poetry</code>, patch it to use the <code>-core</code> variant. | |||
</ | |||
< | |||
</ | |||
[[Category:Development]] [[Category:Python]] | [[Category:Development]] [[Category:Python]] |
Latest revision as of 07:06, 11 May 2023
A lot of Python packages use the setuptools or distutils framework. This mean that the build() and the package() section looks a bit different compared to an application which uses make.
Considerations
pkgname
Package name for a Python library must be prefixed with py3-.
For an 'executable' (for example, black
, binwalk
), you generally don't need to prefix it.
There’s no exact rule if the prefix should be used for tools and applications written in Python, it varies.
arch
- noarch
- Use for pure Python packages (i.e. without compiled code).
- all (and others)
- Use for packages with native extensions (i.e. with compiled code). Do not add python3 to depends= (it's auto-detected via dynamic linking to python library).
source
Most Python packages are published in PyPI(the Python Package Index). If the package has a source tarball available in PyPI (that’s true for most packages), and it contains tests (some explicitly remove them from PyPI), you should reference it in source= as:
https://files.pythonhosted.org/packages/source/${_pyname%${_pyname#?}}/$_pyname/$_pyname-$pkgver.tar.gz
where _pyname is the real name of the Python package.
Otherwise, use the normal upstream git tarballs.
Examples
pep517 invocation
pkgname="py3-foo" ... depends="py3-bar py3-baz" makedepends="py3-gpep517 py3-setuptools py3-wheel python3-dev" checkdepends="py3-pytest" subpackages="$pkgname-pyc" ... build() { gpep517 build-wheel \ --wheel-dir dist \ --output-fd 3 3>&1 >&2 } check() { python3 -m venv --clear --system-site-packages testenv testenv/bin/python3 -m installer dist/*.whl testenv/bin/python3 -m pytest } package() { python3 -m installer -d "$pkgdir" \ dist/*.whl }
Depending on the build-backend
in the pyproject.toml, you might need py3-setuptools or py3-flit-core or py3-poetry-core or py3-hatchling at build time. If a project specifies literally flit
or poetry
, patch it to use the -core
variant.