Skip to content

Support for numpy >= 2.0.2 #432

Description

@envelio-cb

I am working on upgrading our ecosystem to use numpy >= 2.0.2 which currently breaks at your package.

Afaik you don't use numpy in your code except for testing. Thus, I am wondering if you can either drop the dependency and add it as dev-only dependency or if you can be less strict in the versioning of numpy and support numpy >= 2.0.2.

Here is also a list of the numpy ecosystem compatibility with numpy 2.0:
numpy/numpy#26191

Kind regards

Activity

  1. changed the title [-]Support for numpy >= 2.0.2[/-] [+]Support for numpy >= 2.0.2 and pandas >= 2.2.2[/+] on Aug 27, 2024
  2. changed the title [-]Support for numpy >= 2.0.2 and pandas >= 2.2.2[/-] [+]Support for numpy >= 2.0.2[/+] on Aug 27, 2024
  3. arredond commented on Oct 4, 2024

    @arredond
    Contributor

    +1 to this! Also in general to not setting upper bounds to package versions unless strictly necessary.

    I made a similar comment about this here #427 (similar case that's affecting us but for the pyarrow < 17.0 limitation

  4. sshevlyagin commented on Oct 9, 2024

    @sshevlyagin

    +1

  5. jslorrma commented on Oct 26, 2024

    @jslorrma

    +1

  6. Bendik-ml commented on Nov 22, 2024

    @Bendik-ml

    +1 👯‍♂️

  7. tblatrille commented on Dec 10, 2024

    @tblatrille

    +1

  8. jprakash-db commented on Jan 31, 2025

    @jprakash-db
    Contributor

    Pandas and numpy has compatiblity issues, numpy version 2 is only supported after pandas 2.2.2 and any version before that is not supported. - https://pandas.pydata.org/docs/whatsnew/v2.2.2.html#pandas-2-2-2-is-now-compatible-with-numpy-2-0

  9. rgommers commented on Jan 31, 2025

    @rgommers

    Pandas and numpy has compatiblity issues, numpy version 2 is only supported after pandas 2.2.2 and any version before that is not supported

    Newer versions of one package only being compatible with newer versions of another package is perfectly normal, rather than a problem that is relevant to this package. This is still a problem, so there is no reason to close this issue.

    Also in general to not setting upper bounds to package versions unless strictly necessary.

    That is entirely correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions