What to print for "gplately.__version__"?

[jcannon-gplates]

My development version of gplately prints the PyPI release version, instead of the development version, with gplates.__version__.

Currently it appears that, between official releases, we need to set this to None so that the git version is used?

However, there's also a version here (in the __init__.py), which is referenced by pyproject.toml here.

PyGPlates uses PEP 440 versioning which has the .dev suffix - see here.

So maybe gplately can also use PEP 440? And maybe we can update the development version automatically (eg, when merging a pull request).

By the way, the new pyproject.toml in pyGPlates (to be released soon) extracts the version from a specific file (so the version only needs to be changed in one place):

#
# Extract version from 'PYGPLATES_PEP440_VERSION' variable in 'cmake/modules/Version.cmake'.
#
[tool.scikit-build.metadata.version]
provider = "scikit_build_core.metadata.regex"
input = "cmake/modules/Version.cmake"
regex = 'set\(\s*PYGPLATES_PEP440_VERSION\s*(?P<value>\S+)\s*\)'

...however, for gplately, the current approach seems fine (version = {attr = "gplately.__version__"}). I guess I had to do it differently in PyGPlates because it's a C++ extension (not pure Python).

[jcannon-gplates]

Also, I know this was addressed in #253, but maybe once we have dev versions that are different than the official PyPI release version we can then remove the warning here? It's great that you can currently disable it with an environment variable, but I have to remember to set it, or to change __init__.py.

[michaelchin]

Also, I know this was addressed in #253, but maybe once we have dev versions that are different than the official PyPI release version we can then remove the warning here? It's great that you can currently disable it with an environment variable, but I have to remember to set it, or to change __init__.py.

I think the warning message is useful. It sends users a clear message that they are using unstable code. It is a very useful reminder for me.

[jcannon-gplates]

Bonus points for specifying which version a function/class was added/modified (in the API documentation).

I currently do this in pyGPlates manually. For example, I'll add a new parameter to a function and manually specify which version this happened in the documentation, for example, it says Changed in version 0.26: anchor_plate_id no longer defaults to zero in pygplates.RotationModel.get_rotation().

Note that I'm still using pre-1.0 versions, so I don't yet explicity use the PEP440 .dev suffix. However, once pygplates reaches 1.0 I will start using it (and incrementing it every time something changes the API).

[michaelchin]

we can use setuptools-git-versioning 205872c

[jcannon-gplates]

Nice👍. So this now essentially uses PYPI_VERSION, right?

[michaelchin]

Nice👍. So this now essentially uses PYPI_VERSION, right?

Yes, the Python code in init.py will read the gplately package metadata to get the version number so that the pip package version is always the same with the gplately.version.

This is just a proposal from me. There are other ways to do it. I will just leave it there until we come up with a smarter solution.