Python package policies: Difference between revisions
(Updates per latest feedback on alpine-dev) |
mNo edit summary |
||
Line 5: | Line 5: | ||
== Guidelines == | == Guidelines == | ||
* Prefix Python 3 libraries with py3-, and Python 2 libraries with py2-. Do not prefix programs (distinct from libraries) at all. | |||
== General Template == | == General Template == |
Revision as of 23:57, 19 March 2019
Python packages in Alpine Linux should follow a general set of standards for their APKBUILDs.
This material is work-in-progress ... Pending consensus on this approach |
Guidelines
- Prefix Python 3 libraries with py3-, and Python 2 libraries with py2-. Do not prefix programs (distinct from libraries) at all.
General Template
Be sure to make the following changes:
- Update maintainer to yourself
- Set the pkgname to the Alpine package name (prefixed with "py-")
- Set _pyname to the name of the package on PyPI
- Update the version number, pkgdesc, url, and license
- Build it and address any issues that come up
- Read the build output and be vigilant for issues listed in the following sections - the build may complete successfully even though these issues are present
Python 3 only
Note that if you are removing python2 support from a package which previously had it, you should add
replaces="py2-example"
as well. If the old package was a split package, also add
replaces="py-example"
.
# Maintainer: Joe Bloe <joe@example.org> pkgname=py3-alpine-name _pyname=pypi-name pkgver=1.2.3 pkgrel=0 pkgdesc="Example Python package" url=https://example.org arch=noarch license=MIT depends="python3" makedepends="py3-setuptools" _pypiprefix="${_pyname%${_pyname#?}}" source="https://files.pythonhosted.org/packages/source/$_pypiprefix/$_pyname/$_pyname-$pkgver.tar.gz" builddir=$srcdir/$_pyname-$pkgver build() { cd "$builddir" python3 setup.py build } check() { cd "$builddir" python3 setup.py test } package() { python3 setup.py install --prefix=/usr --root="$pkgdir" }
Python 2 & 3
Specify all of the runtime dependencies for both Python 2 & 3 in the makedepends.
# Maintainer: Joe Bloe <joe@example.org> pkgname=py-alpine-name _pyname=pypi-name pkgver=1.2.3 pkgrel=0 pkgdesc="Example Python package" url=https://example.org arch=noarch license=MIT subpackages="py2-${pkgname#py-}:_py2 py3-${pkgname#py-}:_py3" makedepends="python2 python3 py-setuptools" _pypiprefix="${_pyname%${_pyname#?}}" source="https://files.pythonhosted.org/packages/source/$_pypiprefix/$_pyname/$_pyname-$pkgver.tar.gz" builddir=$srcdir/$_pyname-$pkgver prepare() { cp -r "$builddir" "$builddir"-py2 } build() { cd "$builddir" python3 setup.py build cd "$builddir"-py2 python2 setup.py build } check() { cd "$builddir" python3 setup.py test cd "$builddir"-py2 python2 setup.py test } package() { mkdir -p "$pkgdir" } _py2() { cd "$builddir"-py2 _py python2 } _py3() { cd "$builddir" _py python3 } _py() { _python="$1" pkgdesc="$pkgdesc (for $_python)" depends="$depends $_python" install_if="$pkgname=$pkgver-r$pkgrel $_python" $_python setup.py install --prefix=/usr --root="$subpkgdir" }
Common issues
No source package available (only the wheel is on PyPI)
Seek out the upstream source (e.g. GitHub) and swap out the URL.
No tests in PyPI package "(0 tests run)"
Seek out the upstream source (e.g. GitHub) and swap out the URL.
setup.py test downloads a lot of dependencies
Watch out for this and be sure to add any of these packages to checkdepends so that setuptools isn't downloading and testing against packages/versions which aren't in aports.
Different dependencies between py2 and py3 versions
Add depends="..." to the respective _py2 or _py3 subpackage functions.
Alpine+Python projects
aports normalization project
Many Python packages in aports (if not most) do not follow these guidelines.
TODO: obtain consensus and organize this work.
Python 2 deprecation
This material is work-in-progress ... Pending consensus on this approach |
The general approach to Python 2 deprecation and removal requires three broad steps:
- Do not add new python 2 packages to aports, effective immediately.
- In the course of the aports normalization project, drop Python 2 support if it's easy or triage it and make a note for later if not.
- Making judgement calls for difficult packages on a case-by-case basis, based on the upstream's progress/amicability towards a Python 3 port. Upstreams which are unwilling to port to Python 3 should be removed from aports.
TODO: Prepare some discussion place, git repos, scripts, etc, to organize this work.