Can some of the runtime dependencies be loosened? #44
Comments
|
Welp, it looks like test suite passes locally with Some more logs will appear here: |
|
did a quick lookup which parts of
did i miss something? should be possible to go down to v47.0.0 - this is the version where py2 support was removed. tested with a modified pip install poetry
poetry install -v
pip install -U setuptools==47.0.0
python3 -m unittest discover -s tests -vvtest result: Click to expand test results
|
|
@madpah in preparation for this change I would recommend:
|
|
might be related: python-poetry/poetry#3527 |
|
Thanks @jkowalleck. Do we have a collective view as to how to handle CI for when we loosen dependency versions @jkowalleck? Doesn't seem like there is anything OOTB in Poetry to cover us here. |
|
Packages to consider:
|
|
@jkowalleck already researched |
|
importlib_metadata
requirements_parser packageurl-python
toml
typing-extensions types-setuptools
types-toml
@jkowalleck - thoughts on above? |
|
great research, @madpah at some point we should have CI to test once in latest/highest compatible setup, and once in lowest compatible setup. issue i see: there is no way to setup lowest compatible environment nevertheless, we might lower the dependencies, still. |
could not find anything. from [tool.poetry.dependencies]
python = "^3.6"
packageurl-python = "^0.9.4"
requirements_parser = "^0.2.0"
setuptools = "^50.3.2"
importlib-metadata = { version = "^4.8.1", python = "~3.6 | ~3.7" }
toml = "^0.10.2"
typing-extensions = { version = "^3.10.0", python = "~3.6 | ~3.7" }
types-setuptools = "^57.4.2"
types-toml = "^0.10.1"so we could have a which in turn could be installed in a CI/tox setup right after |
|
Note: Will use this as the minimum. |
|
Unfortunately version |
made available with the same name i introduced the wrong usage of sorry for that, @madpah |
|
Indeed - will update and lower back to 3.4.0. |
|
#89 has been merged. |
see #44 Signed-off-by: Jan Kowalleck <jan.kowalleck@gmail.com>
see #44 Signed-off-by: Jan Kowalleck <jan.kowalleck@gmail.com>
see #44 Signed-off-by: Jan Kowalleck <jan.kowalleck@gmail.com>
see #44 updated some locked dependencies to latest versions Signed-off-by: Jan Kowalleck <jan.kowalleck@gmail.com>
|
Will take a look presently. Thanks for thinking about us downstreams!
|
see #44 updated some locked dependencies to latest versions Signed-off-by: Jan Kowalleck <jan.kowalleck@gmail.com>
see #44 updated some locked dependencies to latest versions Signed-off-by: Jan Kowalleck <jan.kowalleck@gmail.com>
|
Yep, was able to ship 0.12.0 without any patches, and all the tests passed the first time, just the way we likes it! Thanks again. |
|
That's epic @bollwyvl. Thanks for confirming. We've of course pushed a few tweaks since 0.12.0 as we've worked through a few niggles - but good to know this is now solved for you. |
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...
The text was updated successfully, but these errors were encountered: