Request for feedback: packaging.p.o discussion on helping downstream packaging

There’s an unfortunate issue with resolver rules and pypi (or even other indexes) in that if all prior versions didn’t also have that pin, you’ll just have the resolver find another version where that wasn’t marked. I don’t think resolvers should ever go “back in time” (to a prior version) to attempt to resolve a conflicting upper limit, as it’s clearly not matching the intent of a limit on that end of the range to backtrack, but that’s not something I’m going to relitigate here.

If you have a known case of this, it’s better to stick something like this in module __init__.py with documentation of the reason, you can even set it up so that users can go “yeah, I know what I’m doing”:

import sys

vi = sys.version_info

# Check use of concurrent.futures.Future before extending this version.
# update `_misc._ensure_annotations.py` before extending this version.
if (vi.major, vi.minor) > (3, 13):
    msg = """This library is not tested for use on python versions above 3.13
    This library relies on a few internal details that are not safe to rely upon
    without checking this consistently.
    """
    if os.getenv("ASYNC_UTILS_UNCHECKED_PY_VER", ""):
        import logging

        msg += """\nThis is not neccessarily broken, but if you encounter an
        issue with it, please be aware that the library has not actively
        chosen to support the python version you have opted into using this on
        *yet*. If you encounter an issue with it, please do still report it.
        """

        logging.getLogger(__file__).warning(msg)
    else:
        msg += """\nYou can change this error to a warning if you are sure it is
        safe and are willing to take the risk on yourself before I have verified
        it by setting the environment variable `ASYNC_UTILS_UNCHECKED_PY_VER`
        to a non-empty value.
        """
        raise RuntimeError(msg)
1 Like

Perhaps the key point here is that dependency pins are more of a general problem than a downstream problem (i.e. they do more harm to direct usage via PyPI than to downstreams), and they deserve their own section.

…but I did?

- Make the test suite work offline. Mock network interactions, using
  packages such as responses_ or vcrpy_. If that is not possible, make it
  possible to easily disable the tests using Internet access, e.g. via a pytest_
  marker. Use pytest-socket_ to verify that your tests work offline. This
  often makes your own test workflows faster and more reliable as well.

Sorry, then I had to miss it.