Bump starting_version for setuptools-git-versioning for new releases

[xylar]

Requirements

• Reviewed ESMPy Documentation
• Searched GitHub Discussions

Affiliation(s)

LANL

ESMF Version

v8.8.0

Issue

In ESMPy 8.8.0, the starting_version for setuptools-git-versioning:
https://github.com/esmf-org/esmf/blob/v8.8.0/src/addon/esmpy/pyproject.toml#L40
was not set to 8.8.0 but remained 8.8.0beta.

When the esmpy conda package gets built from source, the Git tag is not available so it has to resort back to this "starting_version". See:
https://setuptools-git-versioning.readthedocs.io/en/stable/schemas/file/index.html

As a result, it things internally that it is version 8.0.0b0, resulting in warnings like the following any time ESMPy is imported:

/lcrc/soft/climate/e3sm-unified/base/envs/e3sm_unified_1.11.0rc7_chrysalis/lib/python3.10/site-packages/esmpy/interface/loadESMF.py:94: VersionWarning: ESMF installation version 8.8.0, ESMPy version 8.8.0b0
  warnings.warn("ESMF installation version {}, ESMPy version {}".format(

There doesn't seem to be a way short of patching the code to fix this during packaging (e.g. it cannot be overridden by an environment variable). So it would be nice for the 8.9.0 release to make sure this variable gets set to the proper release value.

Autotag

@billsacks

[billsacks]

Thanks for this note, @xylar . We noticed this issue in the ESMPy documentation for the 8.8 release, but didn't realize that it also impacted the conda installation of ESMPy. Is the issue that the conda workflow doesn't get ESMF / ESMPy via a git clone, but instead via some other mechanism?

[xylar]

Correct, it get ESMF and ESMPy from the .tar.gz source code, not from a clone. In general, setuptools-git-versioning is a pain for us because many developers don't handle the fallback correctly. I don't think it's really very useful myself. I would prefer that the source just have the right version hard-coded in it.

[billsacks]

I have made sure that updating this version is on our release procedure for the future. (All of these manual things are a bit error-prone, but it seems like there isn't a good way around this.)

[billsacks]

I looked into taking care of this warning that you get for beta versions, but so far I haven't made that change. Because of the way setuptools-git-versioning changes the version string (leveraging packaging.version), we still end up with a different version string in ESMPy than in ESMF. It wouldn't be too hard to make some changes to remove this warning, but I wasn't sure if we want to do that. Let's discuss that more with the ESMF core team.

I realized that there are two different things and different people may be thinking of different things here: I have not changed behavior for beta versions, but I did fix this warning behavior for the 8.8.1 release version.

[DWesl]

That should work: it would make pip installing new development versions from PyPI a bit harder, but I don't know that that's common, and would take a bit more work to nail down precise commits for bug reports, though most of those are likely to be release versions rather than development.

[billsacks]

@DWesl - thanks a lot for your thoughts. Those are good points, and I hadn't thought about the potential PyPI issue if we start to put development versions there. (We're still investigating what it would take to host ESMPy via PyPI at all.) I guess that, if we want to do that, we'd want to start putting the exact beta version in this Macros file or come up with some other solution.

[billsacks]

@xylar - one thing I wanted to call your attention to, as maintainer of the esmpy conda package, is that I added this file in a new directory outside of the main esmpy source directory. I chose this structure because the code in this version.py file is needed at package build/install time (invoked via a callback from setuptools-git-versioning), but would be confusing to have included in the installed esmpy.

This works for a pip install from source (via pip install . – i.e., setuptools-git-versioning can see this file but it isn't installed with the package), but I'm not sure if there are some things that differ for the conda install that will lead this to cause problems (either making this file unavailable or installing the contents of this build_utils directory somewhere). If so, I can do something different. If you aren't sure off-hand, I can keep an eye on this when the conda build appears for the 8.9.0 release.

[xylar]

Yep, I don't foresee any problem there.