Bumped min numpy version to 1.18

[manodeep]

No description provided.

[pep8speaks]

Hello @manodeep! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2024-08-01 04:27:26 UTC

[manodeep]

@lgarrison Will you please take a look that I didn't reduce the combinations of os/compiler/python/numpy too much? (really, we need to have a separate "does-this-even-compile-and-run-a-simple-thing" workflow and only run the tests on a smaller subset of hardware)

I have dropped python2 completely - so the next release should be a major release (and not a minor/patch release) - possibly even Corrfunc3.0.0. What do you think? Also, should we also take out the code for python2 within the CPython extensions?

[manodeep]

Hmm - now that I think about it a bit more - may be I should drop py2 and numpy in CI first and release a patch version first (ie revert the change to setup.py)

[lgarrison]

Either way is fine with me! I think this looks like good test coverage. Happy to have Corrfunc 3 as the next release, that makes it easy for people to find a version that works with NumPy 2.

[manodeep]

@lgarrison Looks like there were plans to rename the package to corrfunc rather than Corrfunc for Corrfunc3.0. That also seems appropriate - what do you think?

[manodeep]

I reverted the drop of py2 to create one final patch release with python2. Once the tests pass, I am going to merge the branch in and release 2.5.3.

I will then create a new branch to start the process for releasing Corrfunc3

[lgarrison]

@lgarrison Looks like there were plans to rename the package to corrfunc rather than Corrfunc for Corrfunc3.0. That also seems appropriate - what do you think?

Hmm, this would be a breaking change for a lot of people. Should we have a deprecation period, or make the change but at least emit an informative error when using the old name?

[manodeep]

How would we do a deprecation period? The biggest motivation to change the package name is to conform to the python convention - which might be required if we want to migrate to newer packaging methods (i.e., migrate out of setuptools).

If there is an import error, then the error handling would be done by python - I don't think we would be able to emit any message at all - right? Or could we add a dummy Corrfunc.py file within the new package and use that somehow to emit the info message?

[lgarrison]

Yeah, I was thinking of something like a warning period where import Corrfunc would work but emit a message telling people to switch to import corrfunc. I don't know the best way to do this off the top of my head; maybe a symlink of Corrfunc/ to corrfunc/ (with logic to check which path was used in the import) or maybe a Corrfunc.py.