fix(main/python-cmake): Update src checksum

[fornwall]

No description provided.

[robertkirkman]

This has been necessary very frequently for python-cmake. I had been trying to think of a way to solve this problem, but unfortunately I don't really know of any other than disabling the checksum on this package using TERMUX_PKG_SHA256=SKIP_CHECKSUM.

[robertkirkman]

Since the package contents are small and unlikely to change, I had thought of storing a pregenerated version of the package contents in the termux-packages repository and skipping downloading the source code, but that has the downside that is that if it does change after a CMake update eventually, something about it might become slightly outdated and conflict with future CMake or with the requirements for PyPi reverse dependencies of this package, it's unlikely but a possibility.

most of the package functionality is in two very small python files combined with python packaging metadata

~ $ tree /data/data/com.termux/files/usr/lib/python3.13/site-packages/cmake
/data/data/com.termux/files/usr/lib/python3.13/site-packages/cmake
├── __init__.py
├── __init__.py.orig
├── __main__.py
├── __pycache__
│   ├── __init__.cpython-313.pyc
│   ├── __main__.cpython-313.pyc
│   └── _version.cpython-313.pyc
├── _version.py
├── _version.pyi
└── py.typed

2 directories, 9 files
~ $ tree /data/data/com.termux/files/usr/lib/python3.13/site-packages/cmake-4.2.3.dist-info
/data/data/com.termux/files/usr/lib/python3.13/site-packages/cmake-4.2.3.dist-info
├── INSTALLER
├── METADATA
├── RECORD
├── REQUESTED
├── WHEEL
├── direct_url.json
└── licenses
    ├── AUTHORS.rst
    ├── LICENSE_Apache_20
    └── LICENSE_BSD_3

2 directories, 9 files
~ $ cat /data/data/com.termux/files/usr/lib/python3.13/site-packages/cmake/__init__.py
from __future__ import annotations

import os
import shutil
import subprocess
import sys
from importlib.metadata import distribution
from pathlib import Path

from ._version import version as __version__

TYPE_CHECKING = False

if TYPE_CHECKING:
    from typing import Iterable, NoReturn


__all__ = ["CMAKE_BIN_DIR", "CMAKE_DATA", "CMAKE_DOC_DIR", "CMAKE_SHARE_DIR", "__version__", "cmake", "cpack", "ctest"]


def __dir__() -> list[str]:
    return __all__


CMAKE_DATA = "/data/data/com.termux/files/usr"

assert CMAKE_DATA is not None
assert os.path.exists(CMAKE_DATA)

CMAKE_BIN_DIR = os.path.join(CMAKE_DATA, 'bin')
CMAKE_DOC_DIR = os.path.join(CMAKE_DATA, 'doc')
CMAKE_SHARE_DIR = os.path.join(CMAKE_DATA, 'share')


def _program(name: str, args: Iterable[str]) -> int:
    return subprocess.call([os.path.join(CMAKE_BIN_DIR, name), *args], close_fds=False)

def _program_exit(name: str, *args: str) -> NoReturn:
    if sys.platform.startswith("win"):
        raise SystemExit(_program(name, args))
    cmake_exe = os.path.join(CMAKE_BIN_DIR, name)
    os.execl(cmake_exe, cmake_exe, *args)


def ccmake() -> NoReturn:
    if shutil.which("ccmake", path=CMAKE_BIN_DIR) is None:
        raise FileNotFoundError(
            f"'ccmake' is not available in cmake installation at '{CMAKE_BIN_DIR}'. "
            "Perhaps 'ccmake' is not yet inclucded to the package for this platform."
        )
    _program_exit('ccmake', *sys.argv[1:])


def cmake() -> NoReturn:
    _program_exit('cmake', *sys.argv[1:])


def cpack() -> NoReturn:
    _program_exit('cpack', *sys.argv[1:])


def ctest() -> NoReturn:
    _program_exit('ctest', *sys.argv[1:])
~ $ cat /data/data/com.termux/files/usr/lib/python3.13/site-packages/cmake/__main__.py 
from cmake import cmake

if __name__ == "__main__":
    cmake()
~ $ 

[fornwall]

This has been necessary very frequently for python-cmake

Do you know why it keeps happening there? Otherwise we could raise it in an issue in https://github.com/scikit-build/cmake-python-distributions/ and ask if (1) if they know about it and perhaps (2) if they can fix / avoid it in the future?

Surely it's a bad practice in general to change the release afterwards regularly.

[robertkirkman]

That's a good idea, I've opened an issue here:

• release checksum problem scikit-build/cmake-python-distributions#687

[robertkirkman]

Upstream has applied something that might help with the problem,

so the next time python-cmake is automatically updated, we will find out if the problem is still happening or not.

[robertkirkman]

Upstream's fix was applied after the last release, so we will still need to do this hopefully only one more time. I guess I will make the PR for that.