Why were these maximum pins added? Specifying a range of dependency versions or a minimum version when you for sure know that other versions won't work and/or creating separate lockfiles for use in CI that are automatically updated is one thing, but I don't understand this approach.

Besides the reasons that Neal mentioned, maximum version pins pose a security risk. Case in point, cryptography is pinned to <= 36.0.0, but that version is vulnerable to CVEs.

Why were these maximum pins added?

As interim solution as part of getting the unit tests working again, see https://pagure.io/pagure/pull-request/5365

Besides the reasons that Neal mentioned, maximum version pins pose a security risk. Case in point, cryptography is pinned to <= 36.0.0, but that version is vulnerable to CVEs.

We hit a catch-22, new PR's were not merged because the unit tests were always failing, no one could really tell if it was because of issue that came from higher python package versions or the actual change within the PR.

So I pushed for upper limits to get the unit tests running again after investing a few weeks into it. Working unit tests allowing us since then to merge new PRs, which is for now more valuable and required to work on further improvements and to get rid of tech depths.

It requires a second, or even third or fourth, iteration to remove the max pins and move to require none specific or a minimum versions only.

A lot removed with https://pagure.io/pagure/pull-request/5463 already. I'll work on more version pin removals.