Closed lvankampenhout closed 1 year 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
The logic outlined in the _version.py
file is:
_version_setup.py
(written by setuptools_scm
)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.
Closing issue
Small inconsistency that I found when installing a new development version of Parcels.
_version_setup.py
contains: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:
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:Not sure what the solution is.