ParallelSSH/ssh2-python

ssh2-python 1.1.1 on Python 3.7

sand-box opened this issue · 7 comments

sand-box commented

Bug reports

When doing pip install -U ssh2-python using Python 3.7 on Windows, pip updates to ssh2-python 1.1.1 and tries to compile the package and fails. I assume support for Python 3.7 was dropped (#196), so compilation failure is ok. But pip should then not update to version 1.1.1 and stick to the latest supported version.

Steps to reproduce:

  1. pip install -U ssh2-python using Python 3.7 on Windows
  2. Link.exe failed with exit code 1181 / libssh2.lib not found

Expected behaviour: ssh2-python 1.1.1 should not be found via pip install -U because Python 3.7 support was dropped

Actual behaviour: pip is trying to build 3.7 binary

pkittenis commented

Hi there,

Thanks for the interest.

Can add Python 3.7 windows builds back, code still supports 3.7. For now can install the previous version with pip install ssh2-python==1.0.0

sand-box commented

Hi,
from my side, there is no need to build back for 3.7, because 3.7 is EOL. But PyPI should not provide package version 1.1.1 for Python 3.7, but instead provide 1.0.0 as latest supported version.

Pinning version to 1.0.0 in requirement sheets is a workaround, yes. Just wanted to point to this, to avoid that one must manually edit all requirement sheets to avoid breaking automated legacy build pipelines.

fruch commented

Which version of pip is it, sounds like a bug if pip is not using correctly the classifiers

sand-box commented

Tested with pip 24.0 and pip 23.3.2 and pip 23.2.1 (Python 3.7.9 on Windows). All of them fail.

enkore commented

Which version of pip is it, sounds like a bug if pip is not using correctly the classifiers

Unless something has changed recently (which is entirely possible in the packaging ecosystem), pip and friends never processed trove classifiers, because they're intended for human consumption. There's python_requires in setup.py/cfg and requires-python in pyproject.toml, respectively , however, I don't think these factor into dependency resolution (edit: they do). I believe pip first resolves dependency versions and then picks a concrete distribution (wheel, bdist, sdist) for each dependency.

So the correct fix would be to put requires-python = ">=3.8" in the pyproject.toml or the equivalent incantation into setup.py and/or setup.cfg (they're like pokemons, we caught them all). This should cause pip to try dependency resolution again with a lower package version.

pkittenis commented

Such a file does not exist and no requires python is specified, because 3.8 is not required. Pip is doing the right thing in absence of a wheel which is to try to compile from source.

pkittenis commented

Builds windows wheels for Python 3.7+ as of 1.1.2.post1.