OceanParcels / Parcels

Main code for Parcels (Probably A Really Computationally Efficient Lagrangian Simulator)
https://www.oceanparcels.org
MIT License
294 stars 135 forks source link

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

Closed lvankampenhout closed 1 year ago

lvankampenhout commented 2 years ago

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.

erikvansebille commented 2 years ago

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

VeckoTheGecko commented 1 year ago

The logic outlined in the _version.py file is:

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.

erikvansebille commented 1 year ago

Closing issue