Fix version number not being preserved in wheels

[abrammer]

Make sure that the wheel distributions include the versioneer details correctly.

• Closes __version__ in pip wheel is mangled #361
• Tests added - added test in deploy to install and check internal version
• Passes git diff origin/main **/*py | flake8 --diff
• Fully documented
  N/A ?

Tests for this need to be local for now,

python -m build -w
pip install dist/pyresample*.whl
python -c "import pyresample; print(pyresample.__version__)"

[djhoese]

Thanks for making this.

For tests, is there something we could look for in the wheel's files that wouldn't require actually installing the wheel? Since wheels are just zip files I wonder if we could unzip one and grep for something in the version file. Maybe add something to https://github.com/pytroll/pyresample/blob/main/continuous_integration/build-manylinux-wheels.sh?

[codecov]

Codecov Report

Merging #363 (afbdc43) into main (91b8ba7) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #363      +/-   ##
==========================================
- Coverage   93.30%   93.29%   -0.01%     
==========================================
  Files          48       48              
  Lines       10022    10022              
==========================================
- Hits         9351     9350       -1     
- Misses        671      672       +1     

Flag	Coverage Δ
unittests	93.29% <ø> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
pyresample/utils/cf.py	88.46% <0.00%> (-0.43%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 91b8ba7...afbdc43. Read the comment docs.

[abrammer]

Yeah, unzipping and checking the pyresample/version.py would be pretty simple.

pro or con of running the full test suite on each wheel. I got it running for everything but the 32 bit linux, but notably the windows 3.6 tests fail, not sure if it's a legit fail or a just an actions things.

example of the deploy workflow with tests here, dropped the upload jobs from this file for test purposes.
https://github.com/abrammer/pyresample/runs/2668214477?check_suite_focus=true

[djhoese]

Looks like the failure is due to the way rasterio was installed. So not necessarily a pyresample issue.

Running all the tests for the wheels might be overkill. I'd be OK with replacing the pytest call in your version of the actions with the version import and make sure "unknown" isn't in it. Otherwise I would hope that we can safely assume that building a wheel doesn't completely destroy the rest of the package functionality. I could see an excuse for also attempting to import the cython extensions, but 🤷‍♂️.

[coveralls]

Coverage decreased (-0.01%) to 93.284% when pulling afbdc43 on abrammer:fix_pypi_wheel_version into 91b8ba7 on pytroll:main.

[abrammer]

Pushed the much simpler version check, just import and check 'unknown' isn't in the __version__ rather than running the full test suite.
Example fail on the old setup.cfg : https://github.com/abrammer/pyresample/actions/runs/876423241
Example success on this PR setup.cfg: https://github.com/abrammer/pyresample/actions/runs/876422055

[zxdawn]

I tested this PR. But it still doesn't work for installing it on a node without Internet.

$ pip install -e .
$ python

$ import pyresample
$ pyresample.__version__

'0+unknown'

[abrammer]

@zxdawn can you detail the steps you took. It looks like you transfered the repo to the node? Installing from the repo, relies on git to work out the version. If you didn't transfer the .git or have git installed on the node. Unknown might be the expected result.
This PR was tackling the wheel versions from pypi.

You could transfer one of the wheels to the node instead, and install that and then this PR would be relevant and should fix the issue. There are corrected built wheels in the artifacts from the success example in my previous comment here.
(Not that familiar with versioneer so might have missed something)

[zxdawn]

@abrammer Thanks for the PR. Here're the details:

1. Clone the repo to the admin (the node with Internet)
2. Installed the modified repo
3. The version is correct on the admin, but not on the compute node which is without the Internet. Note that admin and compute node share the same storage.

BTW, I got this issue today and it worked well in the last few days ... Strange.

[abrammer]

Does the main branch work? I'm thinking it's possibly unrelated to the PR.

The related issue #361, might be the better place to discuss the issue if it's not related to the changes of the PR.

[zxdawn]

Does the main branch work? I'm thinking it's possibly unrelated to the PR.

The main branch also doesn't work.

I'm not familiar with the pip and not sure whether this PR should fix this problem. What's your opinion, @djhoese?

[djhoese]

@zxdawn So you are pip install -e . on the admin/head node of a cluster and then using that shared installation directory (shared between nodes) and when you check the version you get unknown?

Installing things in editable mode (the -e in your pip) seems like a questionable approach on a multi-node cluster. My guess is that versioneer is creating a version.py that checks git to figure out the version. This is because of the editable mode. BUT this requires git to be installed on the node running the python code and importing/running the version.py module (as @abrammer said). I would be surprised this ever worked unless:

1. You had git installed in some environment and didn't realize it and were using that on the child nodes. Or:
2. You were installing it with pip install . (no -e) which probably should have worked in current main but should definitely work with this PR's fix. Or:
3. Versioneer has some dependence on the version of git installed and your nodes have different versions. Wild guess and unlikely, but still want to say it.

[zxdawn]

@djhoese Thanks for your suggestions!

1. The git is available at /use/bin/git on the admin, but not on the compute node. I installed the git in the conda environment and pip install -e . works again now ;)
2. Yes, pip install . works without the need for git.

[djhoese]

@abrammer Thanks for putting in this work. It looks like this is all behaving as expected. @mraspaud do you have any issues with this? Otherwise I'm thinking a merge and a patch release of pyresample this week.

[djhoese]

Thank you!