Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding bounds for numpy in the build requirements and Adding version for build from source #579

Closed
fnhirwa opened this issue Aug 15, 2024 · 0 comments · Fixed by #581 · May be fixed by #580
Closed

Adding bounds for numpy in the build requirements and Adding version for build from source #579

fnhirwa opened this issue Aug 15, 2024 · 0 comments · Fixed by #581 · May be fixed by #580
Labels
feature request A tag for feature requests

Comments

@fnhirwa
Copy link

fnhirwa commented Aug 15, 2024

Is your feature request related to a problem? Please describe.

Currently when I install the library from pypi, with the current version of numpy greater than 2, pmdarima raises error of binaries incompatibility, this requires users to freeze the numpy to the version greater than 1.21.2 yet less than 2.0.

Should you add bounds to the requirements inplace during the implementation of numpy 2 support #578 this will prevent users from usually handling the version errors manually.

Another issue I noticed when I built the library from source is that the version is fixed to 0.0.0
image

I understand that you decided to make it default to 0.0.0 for local development and non-tagged commits bumping the version in the __init__ file at every release would be very easy for bug reporting and no confusion for those installing the library from the source.

Describe the solution you'd like

Changing the requirements.txt file with version bounds

numpy>=1.21.2
to numpy>=1.21.2, <2.0

Tried this locally and when I added bounds using make develop && make install gave me version less than numpy 2 and when the bound was removed I was getting the latest numpy version.

Describe alternatives you've considered

If this PR #578 could be quickly merged we should not need these requirements modifications.

Additional Context

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request A tag for feature requests
Projects
None yet
1 participant