Expose pynxtools version

[mkuehbach]

Add creator, and creator_version to root and allow other modules to get pynxtools version, using scm

[lukaspie]

The same applies here as in FAIRmat-NFDI/pynxtools-plugin-template#25 (review): why do we not rather determine the pynxtools version runtime using importlib.metadata (a part of the standard lib) rather than relying on a version determined at build time?

Here's my reasoning in a longer form:
When writing the NeXus file, the goal should be to record the version of the pynxtools (and its plugin) that actually produced the data. Retrieving the version via importlib.metadata achieves this by reading the version information from the installed distribution metadata, independent of the presence of a Git repository or build environment. In contrast, the setuptools_scm configuration derives the version from the state of the source repository at build time and relies on Git metadata being available. While this is appropriate for generating package versions during packaging, it can become unreliable once the package is installed from a wheel or source distribution, executed in containerized or deployed environments without Git, or run outside the original repository. Using importlib.metadata therefore ensures that the recorded version always corresponds to the installed pynxtools package that generated the output.

Again, I support to record this information, the question is rather how we obtain it.

[rettigl]

Ho about
__version__ = importlib.metadata.version("pynxtools")

in init.py?

[lukaspie]

Ho about __version__ = importlib.metadata.version("pynxtools")

in init.py?

Yes, that would probably a clean solution. Then again, we don't even need that, we can just call importlib.metadata.version("pynxtools") when we need it.

For a discussion around this, see https://discuss.python.org/t/please-make-package-version-go-away/58501

[mkuehbach]

Pipeline failures related exclusively to ref logs of plugins not having creator

[lukaspie]

For the failing plugin tests, we should do this in FAIRmat-NFDI/pynxtools-plugin-template#25 and then on cruft update, we have to regenerate the example files.

Please, before merging, could you append to this test as well? https://github.com/FAIRmat-NFDI/pynxtools/blob/master/tests/dataconverter/test_helpers.py#L155

[mkuehbach]

For the failing plugin tests, we should do this in FAIRmat-NFDI/pynxtools-plugin-template#25 and then on cruft update, we have to regenerate the example files.

Please, before merging, could you append to this test as well? https://github.com/FAIRmat-NFDI/pynxtools/blob/master/tests/dataconverter/test_helpers.py#L155

Test and documentation was added, feature complete.

[lukaspie]

For the failing plugin tests, we should do this in FAIRmat-NFDI/pynxtools-plugin-template#25 and then on cruft update, we have to regenerate the example files.
Please, before merging, could you append to this test as well? master/tests/dataconverter/test_helpers.py#L155

Test and documentation was added, feature complete.

Thanks, but can you please add to the specific tests (i.e. test_writing_of_root_attributes) mentioned as well? That checks that creator(_version) are properly populated.

[lukaspie]

LGTM, assuming the other test is added. Thanks!