adding pyproject / isort

[miili]

• removed requirements.txt
• removed bumpversion
• added pyproject.toml
• added setuptools_scm for version tagging
• updated pre-commit-config.yaml
  • added isort
  • added checks for yaml and json
  • added generic tests

CI

• added pre-commit-action
• unified two actions to single lint action

[miili]

@yetinam, do you want to integrate https://github.com/codespell-project/codespell into pre-commit?

[yetinam]

I think I'd skip codespell for now.

For the CI failures, they seem to be related to the version parsing. I'll look into it in more detail in the next days.

[yetinam]

Hi! There seems to be an issue with the version inference from setuptools_scm. When installing the branch in a clean environment, the version number is 0.0.0. However, running setuptools_scm.get_version in the repo gives the correct version number. This issue is also causing the failing tests. Could you have a look into it?

[yetinam]

I fixed the CI failures but there is still an issue with the version inference. Try running python setup.py sdist bdist_wheel locally. It will build wheels with version number 0.0.0. In addition, it issues warnings that it does not find the subpackages of seisbench, e.g., seisbench.data. We'll need to fix this before merging.

[miili]

version inference should work now, see 4e947ca

It will never report 0.0.0. Maybe remove handling of those exceptions in the .py logic. Revert c282923?

[miili]

It now infers 0.1 because the main branch (which I forked) is not tagged.

[yetinam]

I think the issue is that the tags were not pulled because of how the checkout action works by default. A few commits on main have tags. I added a mitigation for that but let's see what the CI says. You can try running the build command locally on your branch. It gives 0.2.2-dev... which is consistent with the last tag on main.

[miili]

looks good!

[miili]

Are all of the workarounds in c282923 necessary?

[yetinam]

Not so much actually... Check https://github.com/seisbench/seisbench/actions/runs/3894641535/jobs/6648911568 . The inferred version is still 0.1.dev, which is wrong because main has a 0.2.2 tag somewhere.

[miili]

https://github.com/seisbench/seisbench/actions/runs/3894650340/jobs/6648933093 passes now

[yetinam]

Are all of the workarounds in c282923 necessary?

I think the parts in the test are good practice because that makes the test independent of the actual seisbench version. The part for checking version requirements is debatable. But I think it's in general rather practical if for dev-version the model weight requirements are not enforced.

[miili]

The dev in string logic is obscure. You might run into problems between development/production usage.

[yetinam]

https://github.com/seisbench/seisbench/actions/runs/3894650340/jobs/6648933093 passes now

Yes, but it infers seisbench-0.1.dev1+gc1f5b63. I'll cut the "dev" logic (because I admit it's a weird hack) but I'm pretty sure that will make the CI crash again.

[miili]

It looks like main and the maintenance* branches have diverged a little bit. Maybe it would be straight forward to stick to main together with a development branch.

The need for "independent" maintenance branches (imo) is only needed for major versions.

From semantic versioning:

MAJOR version when you make incompatible API
MINOR version when you add functionality in a backwards compatible manner
PATCH version when you make backwards compatible bug fixes

[yetinam]

Yep, fails as expected. There's apparently still some issue with pulling the tags because if you check in your branch history, there is a v0.2.1 tag on your branch and locally it works just fine. I'll have to leave for today but I can look at it again tomorrow. If you find a solution overnight, I wouldn't mind that either ;-)

[miili]

@yetinam ping for workflow

[yetinam]

Perfect, that did the job. Could you apply the same change to the build action too? Then I'll look over the PR tomorrow and can probably merge it.

Regarding the branching model, I'd decouple the discussion from this PR. Maybe you can open a separate issue about it and then we can have a discussion there?

[miili]

The build process should work as is.

[yetinam]

Just saw the error you fixed in the CI. Well, seems I was tired at that last commit. Thanks!

[yetinam]

Merged the PR now. Thanks a lot for this contribution!