Closed ssbarnea closed 1 year ago
I don't know why pip's dependency solver didn't work either, we got these failures when it was unpinned: https://github.com/DiamondLightSource/python3-pip-skeleton/actions/runs/3541575749/jobs/5946003894
Either way, with the new release and flake8 unconstrained works: https://github.com/DiamondLightSource/python3-pip-skeleton/actions/runs/3564433455
Thanks for the quick release!
Thanks for the feedback, @coretl. Yeah, that's strange. It installed flake8==2.3.0
(super old) and Flake8-pyproject==0.9.1
(quite old). No idea why it did that, but not surprised to see that combination break. Maybe I should just remove the version pin entirely if it does not have the intended effect. There are good arguments against it after all.
I always stated that upper constraints are armed time-bombs. Unless you already know that next version will break, don't add the constraint.
How can you know?
Based on my experience most projects survive major version bumps w/o having to change a thing.
pinning... is a nuke.
@ssbarnea Can you explain why the dependency resolution failed in the above case?
Fixed in version 1.2.1, released today.
For what it's worth, the Flake8 dependency of Flake8-pyproject was pinned to
< 6
before this release. So I don't see why Flake8 needed to be pinned separately (as in those mentions). This should have been handled automatically by Pip's dependency solver. And it was, in my experience. I had no issues with CI.Flake8 v6 did introduce some breaking changes with the new major version (as it does, and which is why the pin was put in place), but they didn't affect the parsing of
pyproject.toml
, as far as I can tell, only of Flake8's INI-like config files.