PKGBUILD for Python Script and Python Version Issues [Updated]

EsGeh · 2024-02-13 20:32:54

[EDIT]:
To clarify: I am not talking about problems with a VCS such as git, but about how to package in such a way that it doesn't break whenever arch updates, say from python version 3.10 to 3.11...
(I updated the thread subject and problem description to avoid confusion).

I'd like to create an arch package for my command line script. I followed Arch package guidelines and Python package guidelines.
It works, but the package breaks whenever arch updates its python version.
The package consists of a script

src/backman/commands/backman.py

which imports

src/backman/commands/

.

Repository structure:

.
├── LICENSE
├── PKGBUILD
├── pyproject.toml
├── README.md
├── src
│   └── backman
│       ├── commands
│       │   ├── backman.py
│       │   └── subcommands
│       │       ├── add.py
│       │       ├── edit.py
│       │       ├── __init__.py
│       │       ├── init.py
│       │       ├── log.py
│       │       ├── ls.py
│       │       ├── rm.py
│       │       ├── run.py
│       │       ├── show.py
│       │       └── wd.py
│       ├── _constants.py
│       └── _utils.py
└── tests
    ├── __init__.py
    ├── test_edit.py
    ├── test_ls.py
    ├── test_rm.py
    ├── test_run.py
    ├── test_show.py
    └── utils.py

6 directories, 24 files

src/backman/commands.py:

from backman.commands import subcommands
from backman import _constants as constants
from backman import _utils as utils
...

With the following PKGBUILD and pyproject.toml this results in a single script copied to /usr/bin/backman and the other files copied to /usr/lib/python3.<VERSION>/site-packages/backman/....
So, whenever the VERSION changes after running pacman -Syu, calling $ backman ... from the terminal fails with

Traceback (most recent call last):
  File "/usr/bin/backman", line 5, in <module>
    from backman.commands.backman import main

.

..., because python no longer finds the import in the updated /usr/lib/python3.<NEW_VERSION>/....

So how to deal with this?

force the package to become outdated when the python VERSION changes
make the package invulnerable to python VERSION changes

Also: How to achieve eather?
----

PKGBUILD:

# Maintainer: EsGeh <samuel@esgeh.net>

pkgname="python-backman2"
_name=${pkgname#python-}
pkgver=2.1.0
pkgrel=00
pkgdesc='Tool to help keeping track of how to call cmd line programs for repeating tasks'
arch=(any)
url="https://gitlab.com/EsGeh/backman2"
license=('GPL')
groups=()
depends=("python" "python-click")
makedepends=("python-build" "python-installer" "python-wheel")
checkdepends=("python-pytest")
source=("git+$url#tag=$pkgver")
md5sums=(SKIP)

build() {
	cd "$srcdir/$_name"
	python -m build --wheel --no-isolation
}

package() {
	cd "$srcdir/$_name"
	python -m installer --destdir="$pkgdir" dist/*.whl
}

pyproject.toml

[build-system]
requires = [
	"setuptools",
]
build-backend = "setuptools.build_meta"

[project]
name = "backman2"
description = "Tool to help keeping track of how to call cmd line programs for repeating tasks"
version = "2.0.0"
authors = [
	{name="EsGeh", email="samuel@esgeh.net"},
]
readme = "README.md"
requires-python = ">=3.9"
classifiers = [
    "Programming Language :: Python :: 3",
		"License :: OSI Approved :: GNU General Public License (GPL)",
		"Operating System :: POSIX :: Linux",
]
dependencies = [
    'importlib-metadata; python_version<"3.8"',
		"pyyaml",
		"click",
]

[project.urls]
"Homepage" = "https://gitlab.com/EsGeh/backman2"

[project.optional-dependencies]
dev = [
	"pytest",
	"pytest-cov",
]

[project.scripts]
backman = "backman.commands.backman:main"

[tool.setuptools.packages.find]
where = [ "src" ]

Last edited by EsGeh (2024-02-13 22:27:26)

loqs · 2024-02-13 22:09:22

pyproject_config.html#dynamic-metadata? Did you mean git instead of subversion?

Trilby · 2024-02-13 22:22:36

EsGeh wrote:

... force the package to become outdated when the python SUBVERSION changes

I'm not sure what you mean by "forcing" it (or "outdated" for that matter). But the package will need to be rebuilt with each such python change. This is not unique to your package, or to python. Every AUR package (that relies on libraries / shared object files) needs to be rebuilt when the dependency paths or sonames change.

Also note that this is not your job as a package maintainer, it is the responsibility of every AUR user to rebuild there AUR packages when needed.

EsGeh · 2024-02-13 22:56:22

Trilby wrote:

EsGeh wrote:
... force the package to become outdated when the python SUBVERSION changes
I'm not sure what you mean by "forcing" it (or "outdated" for that matter). But the package will need to be rebuilt with each such python change. This is not unique to your package, or to python. Every AUR package (that relies on libraries / shared object files) needs to be rebuilt when the dependency paths or sonames change.
Also note that this is not your job as a package maintainer, it is the responsibility of every AUR user to rebuild there AUR packages when needed.

Thank you for clarifying that.
In this case I want to depend on a specific python version then, say 3.11.
And I expect

$ pacman -Syu

..., to result in a version conflict to be reported, when the python version updates to >= 3.12, so the user has to reinstall my package from an updated .pkg.tar.x.

Maybe if I update PKGBUILD such that it reads

...
depends=("python=3.11" "python-click")
...

...instead of...

...
depends=("python" "python-click")
...

?

loqs · 2024-02-13 23:14:13

If you require a specific python version that would break a full system upgrade when python in Arch moves to 3.12.

EsGeh · 2024-02-14 00:43:50

loqs wrote:

If you require a specific python version that would break a full system upgrade when python in Arch moves to 3.12.

Bare with me. I am still learning...
Let me rephrase the problem:

Whenever arch moves to a new python version, pythons [url=https://docs.python.org/3/library/sys_path_init.html>module search path</url> changes, say from '/usr/lib/python3.11' to '/usr/lib/python3.12'.
That means every arch package that uses python has to be rebuilt and reinstalled in order to be copied into the new module search path...
If not, it will become broken and report import errors...

If a arch package breaks whenever python gets updated - doesn't that mean it depends on that specific python version?

Trilby · 2024-02-14 01:39:55

But your package doesn't depend on a specific version of python. Don't try to reinvent the wheel: nothing is required of you, your package is fine as it is. It is up to users to rebuilt their AUR packages when dependencies are updated. DO NOT make this harder for them by adding an artificial version dependency. Your package does not depend on a specific version of python, rather it will only run with the version it was build against just like every other AUR package containing executables.

If you really wanted you could add a pacman hook that is triggered by python updates to print a message reminding users to rebuild your package - but that is the most you should do, and I'd not recommend doing even that.

Last edited by Trilby (2024-02-14 01:44:13)

Arch Linux

#1 2024-02-13 20:32:54

PKGBUILD for Python Script and Python Version Issues [Updated]

#2 2024-02-13 22:09:22

Re: PKGBUILD for Python Script and Python Version Issues [Updated]

#3 2024-02-13 22:22:36

Re: PKGBUILD for Python Script and Python Version Issues [Updated]

#4 2024-02-13 22:56:22

Re: PKGBUILD for Python Script and Python Version Issues [Updated]

#5 2024-02-13 23:14:13

Re: PKGBUILD for Python Script and Python Version Issues [Updated]

#6 2024-02-14 00:43:50

Re: PKGBUILD for Python Script and Python Version Issues [Updated]

#7 2024-02-14 01:39:55

Re: PKGBUILD for Python Script and Python Version Issues [Updated]

Board footer