parcels icon indicating copy to clipboard operation
parcels copied to clipboard

version number reported from within the interpreter is inconsistent with tracked version number

Open lvankampenhout opened this issue 2 years ago • 1 comments

Small inconsistency that I found when installing a new development version of Parcels.

_version_setup.py contains:

__version__ = version = '2.3.1.dev239+g31f81d51'
__version_tuple__ = version_tuple = (2, 3, 1, 'dev239', 'g31f81d51')

The install directory is named lib/python3.8/site-packages/parcels-2.3.1.dev239+g31f81d51-py3.8.egg

However, when querying the version from within Python I get:

parcels.__version__
'v2.3.0-239-g31f81d51'

So with 2.3.0 instead of 2.3.1. This differences arise from the code in _version.py, which queries git. Doing this command by hand gives:

git -C . describe --tags
v2.3.0-239-g31f81d51

Not sure what the solution is.

lvankampenhout avatar Jun 30 '22 09:06 lvankampenhout

Very strange, especially because Parcels v2.3.1 doesn't even exist...

See https://github.com/OceanParcels/parcels/releases and https://anaconda.org/conda-forge/parcels. So no idea where this _version_setup.py gets its version number from

erikvansebille avatar Jun 30 '22 10:06 erikvansebille

The logic outlined in the _version.py file is:

  • Development installations: Assumes the presence of a git repo, version is dynamically determined by git
  • Released version installations (i.e., no git repo): use the variables defined in _version_setup.py (written by setuptools_scm)

https://github.com/OceanParcels/parcels/blob/6d910191994b659601459520741c7b7f2930b2cc/pyproject.toml#L34-L36

Hence the contents of the _version_setup.py file is not important in the developer case, and for released versions the variables in _version_setup.py seem to be correct. In both cases the parcels.__version__ variable should be used as the source of truth, which seems to be correctly specified in this case.

Related: https://github.com/OceanParcels/parcels/pull/1392#issuecomment-1621169578 .

Just wondering, is this impacting your use of the package @lvankampenhout? Are there side-effects of the folder naming, or is it mainly about the inconsistency itself? I agree that ironing out the inconsistency would be nice, but also likely quite low-priority if its a dev-only, non-impactful quirk.

EDIT: Sorry, just realised that this issue is from 2022 and not 2023. I think this can be safely closed.

VeckoTheGecko avatar Aug 28 '23 17:08 VeckoTheGecko

Closing issue

erikvansebille avatar Sep 04 '23 06:09 erikvansebille