Asking packagers to add upper bounds is less of a speed-hack vs. just the correct thing to do. What's interesting about conda-forge is that upper bounds can als

Asking packagers to add upper bounds is less of a speed-hack vs. just the correct thing to do. What's interesting about conda-forge is that upper bounds can also be added later on via a "repodata patch". I'm glad upper bounds can be updated, that definitely seems like the right approach. As a challenge on "just the correct thing to do", how should someone releasing a package using pandas specify an upper bound? Many basic dataframe uses will work just fine with pandas 3, whenever that happens. Some dataframe uses will break even in future minor releases. It's not clear to me that packagers can reliably predict that future. Another example of upper bounds causing pain: I mostly use poetry which unfortunately makes overrides extremely hard. A bunch of small Django packages work fine in Django 4 but haven't been updated in years and specify they only work for Django 3.x releases. The poetry folks say it's a packager problem, the packagers never respond to a PR, and off I go to make an internal fork of yet another library.