Temporary fix for version dependency issues

[ljlamarche]

Description

This PR pins the version of numpy and python used in pyproject.toml and clarifies in the documentation that apexpy is currently not compatible with numpy 2.0 and python 3.12. A new minor release should be published to help users avoid some confusion with installation issues.

This is a temporary fix for #134 and #135. These issues should not be closed as more comprehensive fixes should be implemented in the future.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Release candidate

How Has This Been Tested?

Installation has been tested in a clean Python 3.11 environment to ensure expected behavior (successful installation of apexpy with numpy 1.26). Installation in a python 3.12 behavior fails, but it is now documented that apexpy does not support python 3.12.

From apexpy root directory:

pip install .

Test Configuration

• Operating system: MacOS
• Python version number: 3.11/3.12
• Compiler with version number: gfortran 13.1.0

Checklist

• [x] Make sure you are merging into the develop (not main) branch
• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my own code
• [ ] I have commented my code, particularly in hard-to-understand areas
• [x] I have made corresponding changes to the documentation
• [x] My changes generate no new warnings
• [ ] I have added tests that prove my fix is effective or that my feature works
• [ ] New and existing unit tests pass locally with my changes
• [ ] Any dependent changes have been merged and published in downstream modules
• [ ] Add a note to Changelog.rst, summarising the changes
• [x] Add yourself to AUTHORS.rst and .zenodo.json

[ljlamarche]

Re updating unit tests, agreed. That would be adding 3.11 and 3.12 to this line, correct?

https://github.com/ljlamarche/apexpy/blob/aaf50742fd4d4ad38c16205cbfdfbc85260b5565/.github/workflows/main.yml#L20

We'd expect 3.12 to fail at this point.

[aburrell]

I just added up to 3.11, since we aren't supporting 3.12. We can add that in when we expect it to succeed.

[ljlamarche]

Sounds good. Just so you know, when you install in python 3.12, it still gives the error listed in #135 not a convenient "not supported" message unfortunately. It looks like pip tries to build the package before checking if it's a supported version, and I couldn't figure out if there was a way to make it act any differently.

[aburrell]

@ljlamarche the tests are all working now! Have a go at getting them to pass, I'll check back in tomorrow.

[ljlamarche]

I think I fixed the unit tests so they pass, but now it looks like there's an error with reporting the tests? Will try to look more tomorrow...

[aburrell]

Ok, the current problem is that pytest-cov isn't creating an output file. I don't know why, the commands work locally on another package for me, but also fail locally (running in test directory). I am not sure how to debug this.

[aburrell]

Ok, I had one more idea. The new command work locally, but not here 😢

[aburrell]

Alternative is to remove coveralls for now.

[ljlamarche]

I don't want to rehash things you've already tried, but are we using the Coveralls GitHub Action? The most common reason I've found for GH Actions to mysteriously stop working is version updates in these that you need to include in the workflow file.

[aburrell]

@ljlamarche yes, it's basically required to use now, so we're using it. The main problem is that that tests aren't generating a coverage file (in any format) after they run.

[ljlamarche]

Ok, I have no other brilliant ideas... Go ahead and disable for now if you're comfortable with that.

[aburrell]

@ljlamarche we did it!