Thanks for this!
I know poetry makes it easy lock every little thing down, and it makes testing easier, higher assurance, yadda yadda, but practically, it's quite inflexible when the effective ranges are very small... and on a self-declared lib to boot.
Specifically, hooray for declaring a setuptools dependency: so many pkgutils-using packages forget to.
However the size of the range covered by setuptools ^50.3.2 makes it relatively hard to appease (as in: exactly 1 version).
Selfishly, this is blocking me downstream in packaging this and ultimately jake 1.x for conda-forge.
The same goes for importlib_metadata which unfortunately gets pinned in a number of packages, and seems to change a lot for a backport package.
Anyhow: would the maintainers be open to a PR that:
- loosened the range of e.g.
setuptools to be something more like >=50.3.2,<59
- added a CI test excursion for the lowest and highest bound
In the meantime, I may try patching the pin over on conda-forge and running the full test suite...
Thanks for this!
I know poetry makes it easy lock every little thing down, and it makes testing easier, higher assurance, yadda yadda, but practically, it's quite inflexible when the effective ranges are very small... and on a self-declared
libto boot.Specifically, hooray for declaring a
setuptoolsdependency: so manypkgutils-using packages forget to.However the size of the range covered by
setuptools ^50.3.2makes it relatively hard to appease (as in: exactly 1 version).Selfishly, this is blocking me downstream in packaging this and ultimately
jake 1.xforconda-forge.The same goes for
importlib_metadatawhich unfortunately gets pinned in a number of packages, and seems to change a lot for a backport package.Anyhow: would the maintainers be open to a PR that:
setuptoolsto be something more like>=50.3.2,<59In the meantime, I may try patching the pin over on conda-forge and running the full test suite...