execfile has a dependency to the future / past module

[ReimarBauer]

at least for building by boa and conda we need future in the host requirement. This includes past

We need a different way to get the result of execfile('mslib/version.py') in https://github.com/Open-MSS/MSS/blob/develop/setup.py#L33

[matrss]

We should probably get rid of setup.py entirely and replace it with only setup.cfg (if possible?), or better yet pyproject.toml. That would solve the execfile issue as well.

[ReimarBauer]

The reason of execfile there was not to have to enter the versions string again everywhere.

When doing a conda build I have to add the string again into the feedstock meta.yaml. This decreases the value of the entry in setup.py. But it is worth to have that mostly dependent on the __version__ entry

This may be a solution. https://stackoverflow.com/questions/71193095/questions-on-pyproject-toml-vs-setup-py describes version = {attr = "my_package.__version__"}

Currently pyproject.toml is an open issue on conda. https://github.com/conda/conda/issues/12462

[matrss]

The reason of execfile there was not to have to enter the versions string again everywhere.

I understand that. The version directive in e.g. pyproject.toml works the other way around, it automatically sets __version__ of the package so that we don't have to specify that more than once either.

We could even go further and never specify a version in our source code by using e.g. setuptools-scm. That would get rid of the duplication between __version__ and git tags as well. I have no idea how all of that interacts with conda though.

[ReimarBauer]

github tag gives access to a defined source snapshot and we need it on many places. Release, DOI, conda-forge build, etc We are not on pypi but have to take care for dependent libraries as we were there. There are currently a lot developed for packaging. There is not need to tackle this for the next major.

[ReimarBauer]

We have to review this when pixi build is available