Unnecessary `pip` constraint causing build failures

[woodruffw]

Hi there, this is an upstream packaging report for charm-tools version 3.0.6.

It looks like you're currently constraining pip < 23, which will make your package uninstallable on any host with an upgraded pip (specifically, one released this year).

Example failure: Homebrew/homebrew-core#131661

And the actual failure:

pkg_resources.ContextualVersionConflict: (pip 23.0.1 (/opt/homebrew/Cellar/charm-tools/3.0.6/libexec/lib/python3.11/site-packages), Requirement.parse('pip<23,>=1.5.4'), {'charm-tools'})

And a permalink to charm-tools' own constraint:

charm-tools/setup.py

Line 55 in 1847cbe

'pip>=1.5.4,<23',

Unless there's a specific reason why you're listing pip in your install_requires, my recommendation would be to omit it entirely: the Python runtime is meant to carry it. If for whatever reason it doesn't and you absolutely do need to list it, leaving it open ended on the upper bound is probably fine.

[ajkavanagh]

Hi there; yeah, we have quite a lot of legacy pinning to get around issues we had with pip when they were transitioning their resolver during the pip 21+ days. pip 23 fundamentally broke something (that I can't remember) and so we pinned to move forward at that time.

I also notice that you are using Python 3.11, and I'm almost certain we haven't tested charm-tools with py3.11; I doubt you want to carry a patch, but it would be interesting to see if relaxing the pip constraint with py3.11 yields a working charm-tools. Hmm.

[woodruffw]

That's helpful context, thank you!

I think it should be possible for the formula to request a lower Python version, e.g. the 3.10 series. I'll look into that.

[woodruffw]

(If 3.11 is untested on your end, it might be good to enforce that with a python_requires cap in your setup.py 🙂 -- that would have caused Homebrew's package to fail earlier.)

[ajkavanagh]

(If 3.11 is untested on your end, it might be good to enforce that with a python_requires cap in your setup.py slightly_smiling_face -- that would have caused Homebrew's package to fail earlier.)

I mean I could do, but then you'd come back with a bug report saying "doesn't support Python 3.11" :)

We probably need to get it tested with py3.11 and unpin pip (or do a selective python_version pin for py3.10) as we ought to be marching forward and supporting the newer python versions. Also, add the python_requires capability would be a good idea, so thanks for the suggestion!

[woodruffw]

I mean I could do, but then you'd come back with a bug report saying "doesn't support Python 3.11" :)

That's fair, we probably would! But think you could state it as a matter of policy, and we'd pin your package to python@3.10 on the Homebrew side 😉

(And thank you for the fast response here! I believe we can also temporarily fix this on the Homebrew side, until you're ready as an upstream to support 3.11 🙂)