cedadev / nappy

NASA Ames Processing in PYthon (NAPPy) - a Python library for reading, writing and converting NASA Ames files.
BSD 3-Clause "New" or "Revised" License
9 stars 13 forks source link

use __version__ from nappy init instead of version parameter from ini file #53

Closed FObersteiner closed 2 years ago

FObersteiner commented 2 years ago

Addresses https://github.com/cedadev/nappy/issues/49 - this PR deprecates the version parameter from the nappy.ini file. Instead, nappy.__version__ is now used consistently throughout the code (e.g. when specifying the nappy version during the conversion of an NA file to netCDF).

API unchanged. No test added (but could do so).

Note: I see this more as a temporary fix. Ideally, package version is managed by the CI workflow e.g. derived from the latest git tag. @agstephens don't know what your plans are in that respect.

cheers, Florian

FObersteiner commented 2 years ago

as an illustration of my comment above, in a poetry-managed package, I would set the git tag first,

git tag x.y.z
git push --tags

then put that version in the pyproject.toml file like

poetry version $(git describe --tags --abbrev=0)

and finally

poetry build

to build the package. Put the poetry part in a github action and you have an automated workflow.

To correctly show the version number within the package, you put

from importlib import metadata
__version__ = metadata.version("package-name")

in the main __init__.py file.

agstephens commented 2 years ago

Hi @FObersteiner, Changes to nappy have mainly been made in a hurry to deal with operational requirements. For most other packages I just use __version__ rather than using CI for updating. I need to do some reading about Poetry and how it all works. I'll move the above to an issue and accept this PR. Thanks

FObersteiner commented 2 years ago

Hi @FObersteiner, Changes to nappy have mainly been made in a hurry to deal with operational requirements. For most other packages I just use __version__ rather than using CI for updating.

@agstephens thanks for merging. And no worries, I'm totally fine with __version__ being used here. We're using poetry to manage packages at our institute, so that's just with what I'm familiar with, not to say there are no other options.

Independent of what tool you use to manage packages, I think automating the process with git tagging is a good thing as it improves reproducibility - which in turn I think will become more important in science, as we need to include software versions to ensure the reproducibility of our data (processing).