Maint/modernize

[bzah]

Thanks for submitting a PR, your contribution is really appreciated!

Here's a quick checklist that should be present in PRs (you can delete this text from the final description, this is just a guideline):

• Include documentation when adding new features.
• Include new tests or update existing tests when applicable.

[summarize your pull request here]

This PR fixes #69.
The aim is to modernize the tooling surrounding xncml, including but not limited to:

• migrate from setup.py to pyproject.toml
• Make use of ruff instead of flake8, isort, black, etc
• Use the src layout as described in https://packaging.python.org/en/latest/discussions/src-layout-vs-flat-layout/

This also adds a .cruft.sjon file coming from the use of cruft with the ouranosinc template.
Cruft can then be used to update the project structure whenever the template is updated.
However, xncml porject already diverged a little from the original template:

• CHANGES.rst is renamed CHANGELOG.rst
• docs/usage.rst is superseded by docs/tutorial.ipynb
• ruff format replaces black

Breaking changes

• The build system is now using flint instead of setuptools
• setup.py was removed.
• version is no longer fetched from git, but is instead hardcoded in xncml/init.py

TODO

• fix or add ignore of the rules for the pre-commit hook issues
• Add a personal access token named BUMP_VERSION_TOKEN to enable bump-version workflow.
• Add personal access token named OPENSSF_SCORECARD_TOKEN to enable scoreyard workflow.
• Register project on Coveralls, get token and add .coveralls.yml file

[bzah]

This PR adds an AUTHORS.rst file with the information (including public github emails) from the recorded contributors: @andersy005, @huard, @Zeitsperre, @aulemahal, @fmigneault,
If you would prefer to not be mentioned, just comment on this PR I will remove it.

[fmigneault]

Since RST is used, each section could use a .. _changes_x.y.z: to create relevant IDs. On RTD, the current IDs are id1, id2 and so on, which will become invalid as soon as a new version is released.

Note that the bump version config should auto-add this header ID using the version provided.
Example for inspiration: https://github.com/crim-ca/weaver/blob/73fe9a5a1c56047c73648f30e084961777ab806a/setup.cfg#L7-L26

[bzah]

Thanks, that's handy !

[fmigneault]

Consider some make release-conda or similar.

[bzah]

I don't think it's necessary to create a make release-conda as the initial step for the conda-forge release requires manual step to create the conda-forge feedstock and then, when creating new releases, conda-forge should automatically get the pipy release and create a PR on the feedstock.

[Zeitsperre]

In all honesty, I wrote this to provide some guidance for new maintainers. If it's irrelevant (i.e. the project was already on conda), there's no harm in removing it.

Perhaps this kind of information would be helpful in a separate documentation file specific for maintainers creating the project from the cookiecutter template that can be more easily removed?

[fmigneault]

I'm fine either way if it feels overkill for this use case.

I personally prefer to push for the make ... approach because it allows abstraction (CI doesn't need updates if the tool changes) and to keep all the logic together in Makefile rather than spreading it around with custom tweak and combinations of various tool commands.

[bzah]

@Zeitsperre I agree, I think this would fit better in a doc/development/release.rst document as it's rather the job of maintainers and not of the developers.

@fmigneault I also agree. However, one place where most tools are duplicated is the pre-commit config.
I wonder if we can tell pre-commit to run a make lint and make format instead of it fetching these steps from other git repositories.
BTW, that's pretty much the approach of javascripts projects using husky, they define the lint, format, etc, commands once in a versioned package.json and in the pre-commit config of husky, they just call these commands.

[bzah]

Many thanks for your review @fmigneault, there are some xncml specific issues indeed, but I think most of your comments should first be applied to the cookiecutter template.
I can fix these issues here, but I think @Zeitsperre might be interested to upstream some of them.

[Zeitsperre]

@bzah Thanks for the heads-up! I'm still coming back from my vacation, so I'll give this a look as soon as I can.

@fmigneault If you'd like to upstream a few of your changes so that the nearly 10+ projects using it can also benefit from your work, you are more than welcome to open a PR!

[fmigneault]

I'll let @bzah do it. I only did the proposals, but he did all the good work behind these commits 😉

[bzah]

@Zeitsperre no worries, I will be working on this PR and upstream what's relevant in the coming weeks.

[bzah]

It looks like numpy 2.0.0rc1 on python 3.12 breaks some automated tests. I will have a look and try to fix this in another PR.

[Zeitsperre]

@bzah

Once the changes have been merged to the main branch of the template, I think we can fast-forward those changes here and safely merge!

[bzah]

@Zeitsperre I will try to update this branch via cruft tomorrow. I'm away for a month on Wednesday, so I hope I can get something clean and we can merge this one before I leave.

[Zeitsperre]

@fmigneault The changes coming from the cookiecutter template are done, IMO. The last tasks needed now require Admin access (setting tokens for the repo and registering the project on outside platforms).