Arch Linux

Please try rebuilding tmuxp with the attached diff applied and see if that resolves the issue.

Downloaded the PKGBUILD, applied the patch, ran `makepkg -s`. Built fine as expected. Updated the system, including `python-click-8.0.0-1`; currently installed tmuxp produced same error as before (verifying the initial behavior is still present and reproducible). Installed new package with `sudo pacman -U tmuxp-1.7.2-1-any.pkg.tar.zst` - same behavior. Downgraded to `python-click-7.1.2-4` (`sudo pacman -U 'https://archive.archlinux.org/packages/p/python-click/python-click-7.1.2-4-any.pkg.tar.zst'), then checked for upgrades - pacman will happily upgrade to `python-click-8.0.0-1`.

I'm a bit confused; how did this resolve the issue on your machine?

I thought the issue was the requirements causing click version 8 to be rejected, so I removed the limits on the requirements.
This test applies https://github.com/tmux-python/tmuxp/pull/679

This is build tested only.

The issue that that the requirements _should_ cause click version 8 to be rejected, and they were not respected somehow. Although there are two patches now in upstream (mine is the hackier of the two; I hadn't realized someone else had submitted a patch between when I first reported the current issue and when I decided to work on it since they didn't notice the original issue), the root problem remains. That is - the package didn't respect the upstream saying they don't work with a semver major release.

Did you read the link from [1] ?

What is your proposed solution?

[1] https://github.com/archlinux/svntogit-community/blob/855f754c2e021845b4b98c20c52f7179328ccf04/trunk/PKGBUILD#L18

I did indeed. The developer mentioned they'd loosened pinned constraints, and they appear acceptably loose to me - for example, `click>=7,<8`. Usually semver major changes should not be automatically updated. Not all packages reserve breaking changes for semver major releases; colorama is not yet version 1, and so might reasonably introduce breaking changes in semver minor updates (though probably shouldn't in semver patch updates).

As I mentioned elsewhere, it appears possible `pacman` isn't clever enough to deal with multiple versions of an installed library - one up to date, and (possibly more than) one installed at a maximally supported version for current software. The general colloquial term for this problem is "dependency hell" (https://en.wikipedia.org/wiki/Dependency_hell), and is a major motivation for using package managers with automatic dependency resolution.

Okay - dug into the PKGBUILD format a bit further - here's the bit you might have overlooked: https://wiki.archlinux.org/title/PKGBUILD#Dependencies. Looks like pacman _can_ handle version detection. If line 10 is changed from `depends=('python-click' 'python-colorama' 'python-kaptan' 'python-setuptools' 'python-libtmux')` to `depends=('python-click>=7' 'python-click<8' 'python-colorama' 'python-kaptan' 'python-setuptools' 'python-libtmux')`, `pacman` correctly detects the conflict with the new version of `python-click` and does not upgrade `python-click` to version 8. I verified this by changing the PKGBUILD, downgrading `python-click`, rebuilding on my system, reinstalling the package from the local build, and upgrading my system.

It would need to be a depends on a new package python-click7 to avoid a partial upgrade [1]. That is why I was interested in if you had tested resolving the incompatibility with python-click 8.

[1] https://wiki.archlinux.org/title/System_maintenance#Partial_upgrades_are_unsupported

Testing shows using versions as documented on the wiki does not result in a partial upgrade state. Instead, the system stays at its current update state until the conflict is resolved. This is a far superior user experience than randomly breaking unrelated packages on an upgrade, and is likely why pacman supports version constraints. Updating python-click (or python-colorama, which I had to deal with last time) should _not_ break the installed and working tmuxp without warning. Since pacman is clever enough to handle the issue and the upstream reasonably declares they don't support versions which haven't been developed yet, the problem lies somewhere in between.

Regarding the incompatibility patch - I have tested resolving the incompatibility - one of the two submitted patches to resolve it has the same username as the one making this comment (the hackier of the two, so if you grab one I'd suggest grabbing the other; they are fundamentally the same). So, it should be feasible to apply the patch for this distro until it is integrated into the (hopefully next) upstream release.