More Alpine aports/apkbuild conversions. I'm working toward uv, based on the aports APKBUILD. This and py3-gpep517 seem to be dependencies for multiple packages, so might be useful for general Python packaging if not using uv for Python environment management.
This builds successfully, but I have no idea if it works for building other Python packages.
Notes
Apkbuild things I'm not sure how to handle
These are in the aports apkbuild but I don't know how/where they fit.
checkdepends="py3-pytest"
subpackages="$pkgname-pyc"
source="default-bytecode-levels.patch"
# checkdepends causes weird circular behaviour,
# because py3-pytest depends on this down the chain
options="!check"
Hermeticity hacks
Using cut to get the last parts of the Python site-packages path is fragile, but avoids hard-coding the Python minor version. At least, it might be relatively stable. The aim is to cut off the leading /mere/store/python3.14-{hash}/ part, leaving just usr/lib/python3.14/site-packages.
Using files "usr/lib/" feels like too much of a hack given the files built. But I also don't know exactly which files are installed and which are just auxiliary. The output tarball only contains the target subdir tree, so maybe it's fine. As above, this is mainly to avoid hard-coding the Python minor version.
Noarch
The apkbuild architecture is noarch. Mere doesn't recognise this, so I listed aarch64 and x86_64.
Patch file
The patch file isn't used explicitly in the apkbuild. Is it applied in the apkbuild function default_unpack? This is not clear. Including the source doesn't affect the Mere output package. I might need to dig into how Alpine packaging default functions work.
More Alpine aports/apkbuild conversions. I'm working toward [uv][uv], based on the [aports APKBUILD][apk-installer]. This and [py3-gpep517][apk-gpep517] seem to be dependencies for multiple packages, so might be useful for general Python packaging if not using uv for Python environment management.
This builds successfully, but I have no idea if it works for building other Python packages.
[apk-gpep517]: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/py3-gpep517
[apk-installer]: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/py3-installer
[uv]: https://docs.astral.sh/uv/
******
# Notes
## Apkbuild things I'm not sure how to handle
These are in the aports apkbuild but I don't know how/where they fit.
checkdepends="py3-pytest"
subpackages="$pkgname-pyc"
source="default-bytecode-levels.patch"
# checkdepends causes weird circular behaviour,
# because py3-pytest depends on this down the chain
options="!check"
## Hermeticity hacks
Using `cut` to get the last parts of the Python `site-packages` path is fragile, but avoids hard-coding the Python minor version. At least, it might be relatively stable. The aim is to cut off the leading `/mere/store/python3.14-{hash}/` part, leaving just `usr/lib/python3.14/site-packages`.
Using `files "usr/lib/"` feels like too much of a hack given the files built. But I also don't know exactly which files are installed and which are just auxiliary. The output tarball only contains the target subdir tree, so maybe it's fine. As above, this is mainly to avoid hard-coding the Python minor version.
## Noarch
The apkbuild architecture is `noarch`. Mere doesn't recognise this, so I listed aarch64 and x86_64.
## Patch file
The patch file isn't used explicitly in the apkbuild. Is it applied in the apkbuild function `default_unpack`? This is not clear. Including the source doesn't affect the Mere output package. I might need to dig into how Alpine packaging default functions work.