Another weirdness that popped up: I now build pip packages to upload to pypi.org on the oldest possible platform, because if I don’t do that the pypi packages think I need newer deps, tries to install them on older python versions and os’s and fails. So all the pypi uploads are done using setup.py from python3.6. Again, I need to do this until the older OS’s are retired (2028?.. I think rh8 is even longer.)
Well, that will depend on how your build process is creating the version dependency information. Without restrictions, Pip tries to use the newest versions available; it has no way to know ahead of time what will or won’t build successfully on your platform. You can specify range bounds or pins with setup.py, setup.cfg or pyproject.toml, using the common syntax defined by PEP 508.
If you mean that transitively included dependencies are fetching badly-chosen versions with their own logic, that’s a known problem. It should be possible to solve this by making sure that their dependencies are installed first, with a specific version (as long as it satisfies their requirements). But yes, others commonly upload packages that just ask for the newest version of their dependency, expecting the dependency to only improve with future versions; they have no way to know in advance that a new version will be incompatible with their own code. Some developers attempt to future-proof by bounding dependencies to the current major version, but that comes with its own set of problems - especially since Python itself uses rolling deprecations across a few minor versions rather than allowing the major version number to grow, well, like it does for web browsers.
1 Like