more-itertools dependency needs to be at least v8.5 about inflect

[jaraco]

Thanks for the explanation. That makes sense. We once considered adopting lockfiles in workflows at companies where I've worked and I was resistant to them for that reason (stable but stale by default). But I understand the motivations. Let's add the bound.

[jaraco]

While technically correct, v8.5 was released almost four years ago. In my experience, a lower bound is mainly useful in the first few months of a feature's release, as installers pick up the latest version by default and only environments still stuck with old cruft are exposed to the older behavior.

How did you come across this issue? Did it affect you? If so, I'd like to know how so I can update my understanding of the situations affected by unbounded dependencies. Did you run a tool to detect what the bound should be, and if so, which one?

[mertuygr]

I have a direct dependency on an older version of the more-itertools in my codebase, and I am using poetry to manage dependencies. In my case, since we are shipping an application, not a library, the dependencies are locked using a lock file to increase the stability of the application. When I add inflect to my pyproject.toml. Poetry thinks the more-itertools dependency of the inflect is already satisfied while resolving dependencies and gives me the green light since no lower bounds are set in its dependency list. However, I was welcomed with the windowed_complete function missing when I ran the import inflect.

As far as I know, no tool detects a minimum lower cap for dependencies. I would approach this by setting a non-strict lower cap to show possible conflicts for the library users' codebase dependencies. They will take advantage of the latest dependency version as long as there is no upper cap. On the other hand, not setting any caps hides the requirement from the package managers. I am not an expert on this one, though; it is just my two cents.