Pip not choosing the 'newest' PEP440 version available

Question regarding why pip is selecting a different version than I would expect.
Env: python 3.8.13, pip 22.0.4

I have a package in my
This pip command:

pip install -v -v -v  -i https://pypi.org/simple --find-links=/home/steve/Documents/project01/GitRepos/ioif/ioif-core/dist -i https://gitlab.XXXXX.stevens.edu:9090/gitlab-ci/devl  'ioif-core'

The directory used in the --find-link option has a wheel file: ioif_core-0.8.4.post20221107-py3-none-any.whl using PEP440 compliant naming. The devpi index gitlab-ci/devl has an older wheel file for the same package (the below output from pip shows the determined version: 0.8.4.post20220421181059).

pip is installing the 20220421 version rather than the 20221107 and I’m confused as to why? I am probably missing why from the verbose output the factor that is causing pip to select the wheel it is.
The wheel’s METADATA file has the ‘Version: 0.8.4.post20221107’ value.

MTIA for any insights, feedback.

pip output snippet:

  Found link https://gitlab.XXXX.stevens.edu:9090/gitlab-ci/devl/%2Bf/8c7/5f31e11f030b3/ioif_core-0.8.4.post20220421181059-py3-none-any.whl#sha256=8c75f31e11f030b3f4f3141485ceec166afdadb4b430376f6bc4d8fb622fd8d9 (from https://gitlab.XXXXX.stevens.edu:9090/gitlab-ci/devl/+simple/ioif-core/) (requires-python:>=3.7), version: 0.8.4.post20220421181059
[... older version links deleted from this listing ]
Skipping link: not a file: https://gitlab.XXXXX.stevens.edu:9090/gitlab-ci/devl/ioif-core/
Found link file:///home/steve/Documents/project01/GitRepos/ioif/ioif-core/dist/ioif_core-0.8.4.post20221107-py3-none-any.whl, version: 0.8.4.post20221107
Local files found: /home/steve/Documents/project01/GitRepos/ioif/ioif-core/dist/ioif_core-0.8.4.post20221107-py3-none-any.whl
Given no hashes to check 65 links for project 'ioif-core': discarding no candidates
Collecting ioif-core
  Created temporary directory: /tmp/pip-unpack-ei2_nd7p
  Found index url https://gitlab.XXXXX.stevens.edu:9090/gitlab-ci/devl
  Looking up "https://gitlab.XXXXX.stevens.edu:9090/gitlab-ci/devl/%2Bf/8c7/5f31e11f030b3/ioif_core-0.8.4.post20220421181059-py3-none-any.whl" in the cache
  Current age based on date: 73658
  Freshness lifetime from max-age: 315360000
  The response is "fresh", returning cached response
  315360000 > 73658
  Using cached https://gitlab.XXXXX.stevens.edu:9090/gitlab-ci/devl/%2Bf/8c7/5f31e11f030b3/ioif_core-0.8.4.post20220421181059-py3-none-any.whl (452 kB)
  Added ioif-core from https://gitlab.XXXXX.stevens.edu:9090/gitlab-ci/devl/%2Bf/8c7/5f31e11f030b3/ioif_core-0.8.4.post20220421181059-py3-none-any.whl#sha256=8c75f31e11f030b3f4f3141485ceec166afdadb4b430376f6bc4d8fb622fd8d9 to build tracker '/tmp/pip-req-tracker-gv4rtrhy'
  Removed ioif-core from https://gitlab.XXXX.stevens.edu:9090/gitlab-ci/devl/%2Bf/8c7/5f31e11f030b3/ioif_core-0.8.4.post20220421181059-py3-none-any.whl#sha256=8c75f31e11f030b3f4f3141485ceec166afdadb4b430376f6bc4d8fb622fd8d9 from build tracker '/tmp/pip-req-tracker-gv4rtrhy'
Requirement already satisfied: Owlready2>=0.33 in ./.tox/py38-bash/lib/python3.8/site-packages (from ioif-core) (0.35)
Requirement already satisfied: pytz in ./.tox/py38-bash/lib/python3.8/site-packages (from ioif-core) (2022.6)
Requirement already satisfied: pandas in ./.tox/py38-bash/lib/python3.8/site-packages (from ioif-core) (1.5.1)
Requirement already satisfied: urllib3>=1.24.1 in ./.tox/py38-bash/lib/python3.8/site-packages (from ioif-core) (1.26.12)
Requirement already satisfied: numpy in ./.tox/py38-bash/lib/python3.8/site-packages (from ioif-core) (1.23.4)
Requirement already satisfied: python-dateutil>=2.6.0 in ./.tox/py38-bash/lib/python3.8/site-packages (from ioif-core) (2.8.2)
Requirement already satisfied: six>=1.5 in ./.tox/py38-bash/lib/python3.8/site-packages (from python-dateutil>=2.6.0->ioif-core) (1.16.0)
Created temporary directory: /tmp/pip-unpack-tet0a3is
Installing collected packages: ioif-core

Successfully installed ioif-core-0.8.4.post20220421181059
WARNING: You are using pip version 22.0.4; however, version 22.3.1 is available.

NOTE: the wheel is built using

python ./setup.py egg_info --tag-build=post$(date +%Y%m%d%H%M%S) bdist_wheel

to give finer time granularity (so the newest is actually selected).

The presence of the Local files found: indicates to me that the code at line 852 in _internal/index/package_finder.py has identified the indicated wheel files and that it ought to be in the returned list prior to those qualifying pages (non-file URLs). So the question I need to chase down is why the local file isn’t used rather than the older index URL.

Should that not be pip3 install... etc

Yes, it is - I’m running this stuff in an activated 3.8.13 venv, pip -v => pip 22.0.4 from /home/steve/PycharmProjects/ioif-3.8.13/venv/lib/python3.8/site-packages/pip (python 3.8)
Appreciate you taking a look.

I’m confused - the CandidateEvaluator.sort_best_candidate method uses the _sort_key method to determine the max of the candidates - in my case, a list of 65 links, 64 are devpi index links while the 1 file link is the one I think ought to be selected based on the Link.version.post == ‘20221107’. But I don’t see where the tuple returned by CandidateEvaluator._sort_key is being used to sort the list of candidates. And so the best_candidate is not the file link but the ‘newest’ devpi index link with a much lower Link.version value. How badly am I missing something that is comparing the Link.version values?

Found it: The issue is of my doing. The InstallationCandidate.version property has post being a int value, not a str. So the sorting of the int value is causing the selection. And because I had left off the HHMMSS value of the post value for the newer wheel, it is sorted as not the max available. So the version is, as the documentation described in https://peps.python.org/pep-0440/#post-releases, sorted numerically, not in lexical order. So, while ‘20221107’ > ‘20220421181059’ , int(‘20220421181059’) > int(‘20221107’). Things to remember, be consistent about…