Update version range of typing-extensions (>=3.10, <5.0)

[SohumB]

Due to python-poetry/poetry#697, this is necessary to install xarray-dataclasses in any poetry project that directly or indirectly depends on typing-extensions 4+.

The tests pass on 4.3.0, but I do not know the project at all; if there are any further changes that may need to be made, please do let me know.

[astropenguin]

@SohumB Thank you for the PR! Just to confirm, do you mean that because xarray-dataclasses only accepts typing-extensions = ">=3.10, <4.0", it cannot be installed with some packages that depend on typing-extensions = ">=4.0"?

I agree with the idea of loosing the version range, but I also think it would be nice to have an upper limit like typing-extensions = ">=3.10, <5.0" because the future major upgrade of typing-extensions may have some breaking changes. Would it be possible to change pyproject.toml like this?

[SohumB]

That's correct, yes. And that makes sense, just because 4.0 seems compatible doesn't mean 5.0 will also be. I've updated the PR.

[astropenguin]

@SohumB Thank you for the update. pyproject.toml looks good to me, however, running poetry install in the test workflow fails with a warning:

Warning: The lock file is not up to date with the latest changes in pyproject.toml.
You may be getting outdated dependencies. Run update to update them.

Perhaps there is something wrong with the contents of poetry.lock. Could you re-update it by poetry update?

(In my environment built with the included devcontainer, Poetry v1.1.15 failed to update properly. Upgrading Poetry to v1.2.0rc2 by poetry self update --preview solved the problem.)

[SohumB]

I'm not seeing that warning in any of the 3.8/3.9/3.10 tests in the CI run. (And, indeed, running poetry update merely changes the hash without changing anything meaningful.) The warning does show up in 3.7, but that seems to not be the actual cause of failure:

  SolverProblemError

  The current project's Python requirement (3.7.13) is not compatible with some of the required packages Python requirement:
    - pandas requires Python >=3.8, so it will not be satisfied for Python 3.7.13
  
  Because no versions of xarray match >=0.18,<0.20.2 || >0.20.2,<0.21
   and xarray (0.20.2) depends on pandas (>=1.1), xarray (>=0.18,<0.21) requires pandas (>=1.1).
  Because no versions of pandas match >=1.1,<1.4.2 || >1.4.2
   and pandas (1.4.2) requires Python >=3.8, pandas is forbidden.
  Thus, xarray is forbidden.
  So, because xarray-dataclasses depends on xarray (>=0.18, <0.21), version solving failed.

  at /opt/hostedtoolcache/Python/3.7.13/x64/lib/python3.7/site-packages/poetry/puzzle/solver.py:241 in _solve
      237│             packages = result.packages
      238│         except OverrideNeeded as e:
      239│             return self.solve_in_compatibility_mode(e.overrides, use_latest=use_latest)
      240│         except SolveFailure as e:
    → 241│             raise SolverProblemError(e)
      242│ 
      243│         results = dict(
      244│             depth_first_search(
      245│                 PackageNode(self._package, packages), aggregate_package_nodes

  • Check your dependencies Python requirement: The Python requirement can be specified via the `python` or `markers` properties
    
    For pandas, a possible solution would be to set the `python` property to "<empty>"

The problem appears to be that pandas has dropped 3.7 compatibility, so anything downstream of it can't have 3.7 compatibility either.

Should I just remove 3.7 from the github workflows file?

[astropenguin]

@SohumB After checking poetry.lock further, I found that many hashes were unexpectedly removed for some reasons. Could you please check the "File changed" tab to see the diff of poetry.lock? For example, the hash list for pandas (L1102 of the new poetry.lock) is empty but was not empty in the old poetry.lock made by me. I guess this is the root cause of the installation error in Python 3.7.

The problem appears to be that pandas has dropped 3.7 compatibility, so anything downstream of it can't have 3.7 compatibility either. Should I just remove 3.7 from the github workflows file?

No, please keep the workflow for Python 3.7 because I design the dependencies so that the package chooses old xarray (and old pandas) that are compatible with Python 3.7:

xarray = [
    { version = ">=0.18, <0.21", python = ">=3.7.1, <3.8" },
    { version = ">=0.18, <2023", python = ">=3.8, <3.11" },
]

Sorry for asking you many times, but could you re-update poetry.lock with the latest Poetry (1.2.0)? Please let me know if you have some issues on the development construction. I will then share with you poetry.lock made in my environment that works good with Python 3.7.

[SohumB]

Huh, weird. I can't say I understand poetry well enough to understand why those hashes were removed. I've updated to poetry 1.2.0 (from 1.1.14) and rerun poetry update as you asked; let's see if that helps.

[astropenguin]

Thank you for the update! poetry.lock now works no problem with Python 3.7. I will merge your PR and release a new version as soon as possible.

[astropenguin]

@SohumB Now v1.3.1 is available from PyPI. Again thank you so much for your contribution!

[SohumB]

Excellent! and thank you so much for bearing with me through this!

…

On Mon, 5 Sept 2022, 20:03 Akio Taniguchi, ***@***.***> wrote: @SohumB <https://github.com/SohumB> Now v1.3.1 is available from PyPI. Again thank you so much for your contribution! — Reply to this email directly, view it on GitHub <#165 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAQHKGT73WMNSNN4IZO3JTV4XAODANCNFSM55GTOOAA> . You are receiving this because you were mentioned.Message ID: ***@***.***>