Release Candidate v2.0.0

[aburrell]

Description

This is a release candidate for the new, hopefully easier to install, version of apexpy.

Type of change

Please delete options that are not relevant.

• Release candidate

How Has This Been Tested?

Tested installation using local builds and CI wheels. After installation try the simple example on the README to ensure the package is working correctly.

Test Configuration:

• Operating system: OS X Big Sur
• Python version number: 3.8
• Compiler with version number: gfortran 12
• Any details about your local setup that are relevant (e.g., apexpy version/branch)

Checklist:

• [x] Make a TestPyPi release (https://test.pypi.org/project/apexpy/2.0.0/)
• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my own code
• [x] 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
• [x] I have added tests that prove my fix is effective or that my feature works
• [x] New and existing unit tests pass locally with my changes
• [x] Any dependent changes have been merged and published in downstream modules
• [x] Add a note to Changelog.rst, summarising the changes
• [x] Add yourself to AUTHORS.rst and .zenodo.json

[aburrell]

@jklenzing, you probably want to test this out.

[coveralls]

Pull Request Test Coverage Report for Build 3640529419

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+1.3%) to 98.842%

---

Totals
Change from base Build 703:	1.3%
Covered Lines:	358
Relevant Lines:	362

---

💛 - Coveralls

[ljlamarche]

@jklenzing , that was the problem I was having with #99. Specifying gcc didn't fix it for me either, but I haven't gotten around to further debugging. I believe I did manage to test installing from pre-built wheels (#98), so it's just installing locally that's a problem, right?

[jklenzing]

@jklenzing , that was the problem I was having with #99. Specifying gcc didn't fix it for me either, but I haven't gotten around to further debugging. I believe I did manage to test installing from pre-built wheels (#98), so it's just installing locally that's a problem, right?

It turns out the install worked, but I was trying to import from the source code directory, so it was grabbing the local code and not the compiled code.

[ljlamarche]

It turns out the install worked, but I was trying to import from the source code directory, so it was grabbing the local code and not the compiled code.

Ok, I'm still having a bit of trouble with this, so just to be clear:

1. In the apexpy top directory, build apexpy:

   CC=gcc python -m build .

2. From same directory, install apexpy:

   pip install -e .

3. LEAVE the apexpy top directory, go anywhere else:

   cd

4. Start python and try to import apexpy

Is that the correct order of steps to try?

[aburrell]

FYI: PyPi doesn't support the linux wheels, so only the mac and windows wheels were uploaded.

[jklenzing]

Is that the correct order of steps to try?

I used the same steps, but had to use CC=gcc-11 to send it to the homebrew installation instead of clang. I also dropped the -e for the install.

[ljlamarche]

Thank you! I think the -e and testing in the local directory were my downfall (which I think are both effectively the same problem). So is the -e just not an option for building on macOS?

[aburrell]

The -e is not currently supported by meson on any system. Hopefully they'll add it in the future.

[jklenzing]

Thank you! I think the -e and testing in the local directory were my downfall (which I think are both effectively the same problem). So is the -e just not an option for building on macOS?

I think it doesn't work since meson takes priority. I've used -e elsewhere on Mac.

[ljlamarche]

Oh yeah, I've absolutely used -e on other projects. Thank you for clarifying. Do we need to change the docs to reflect this? I think I had explicitly written in to use the -e option.

[jklenzing]

It took a few tries, but I've got this running on a daskhub server as well. I did have to specify CC=gcc pip install . after the python build statement to get the right versions mapped in the compile. All sample tests on the README page are running as expected.

[jklenzing]

Also, pysatMissions local tests using this version of apexpy are working as expected.

[jklenzing]

Did a quick test with pysatMissions using the wheels at the testpypi site: https://github.com/pysat/pysatMissions/actions/runs/3623030093

linux is failing due to lack of wheels, but windows is succeeding. Coverage indicates that tests are being run with apexpy, so something is going right. Given the wheel issue here, though, will probably have to implement something else there for CI tests.

[eli-schwartz]

meson-python is currently working on editable installs (pip install -e support) and it should probably be available in the near future. :)

[aburrell]

@jklenzing I tried to get the installs working on your testing branch at pysatMissions, but couldn't. Maybe it's a testPyPi thing? The error it's giving is odd given that other packages have meson-dependent installs. :/

[jklenzing]

@jklenzing I tried to get the installs working on your testing branch at pysatMissions, but couldn't. Maybe it's a testPyPi thing? The error it's giving is odd given that other packages have meson-dependent installs. :/

My gut thought was that the linux wheels aren't there. Ultimately, if we're not uploading wheels, we'll have to rewrite that area anyway