feat: dynamic versioning for hatch

[Saransh-cpp]

Pull Request description

This PR switches hatch to use dynamic versioning, similar to flit -

scicookie/src/scicookie/{{cookiecutter.project_slug}}/build-system/flit-pyproject.toml

Line 47 in 03377b0

dynamic = ["version"]

and pdm

scicookie/src/scicookie/{{cookiecutter.project_slug}}/build-system/pdm-pyproject.toml

Line 47 in 03377b0

dynamic = ["version"]

in this repository. There are also some minor fixes which I found while using the repo -

• redundant noqa
• typo in workflow file

Fixes #153

How to test these changes

• ...

Pull Request checklists

This PR is a:

• bug-fix
• new feature
• maintenance

About this PR:

• it includes tests.
• the tests are executed on CI.
• the tests generate log file(s) (path).
• pre-commit hooks were executed locally.
• this PR requires a project documentation update.

Author's checklist:

• I have reviewed the changes and it contains no misspelling.
• The code is well commented, especially in the parts that contain more complexity.
• New and old tests passed locally.

Additional information

Reviewer's checklist

Copy and paste this template for your review's note:

## Reviewer's Checklist

- [ ] I managed to reproduce the problem locally from the `main` branch
- [ ] I managed to test the new changes locally
- [ ] I confirm that the issues mentioned were fixed/resolved .

[Saransh-cpp]

Hmm weird, this does not fail locally + if I add the noqa statements, the CI does log a warning.

[Anavelyz]

Hmm weird, this does not fail locally + if I add the noqa statements, the CI does log a warning.

Hi @Saransh-cpp

When you run makim tests.lint this error appears. The noqa was added to find a solution later. On Discord we once talked about it...

[Saransh-cpp]

Oh, I missed that. Thanks, @Anavelyz! Will revert this.

[xmnlab]

@Saransh-cpp thanks for working on that!
I have some questions about that.

• how does hatch handles the version information? using git?
• how to release a new version with hatch?
• I saw that you hard-coded 0.0.1, shouldn't it come from the user input? for example, if the project uses semantic-release, it doesn't work very well with 0.* versions (although I use it 0.* approach anyway), so maybe some uses would like to start with a specific version.
• probably we should offer an option for versioning type dynamic or static

[Saransh-cpp]

Thanks for the quick review, @xmnlab!

---

how does hatch handles the version information? using git?

hatch reads it from __init__.py (similar to the other backends), the only difference being it uses regex to read that, which means that it does not execute functions while looking for the version. Hence, the get_version function would not work with hatch, we'll have to write down the version in the file.

hatch can read version from git too, but that would be another PR (adding VCS versioning to scicookie). My explanation might be a bit confusing, but "dynamic" version here is not the same as "VCS" version, dynamic just means reading the version from a file that is not pyproject.toml and VCS would mean using git tags to automatically set the version. Both of them are Semantic versions, I think.

how to release a new version with hatch?

That would be very similar to the other backends, but it would just require updating the version manually in __init__.py. We would be able to do it without the manual work if the VCS versioning is integrated (hatch-vcs).

I saw that you hard-coded 0.0.1, shouldn't it come from the user input? for example, if the project uses semantic-release, it doesn't work very well with 0.* versions (although I use it 0.* approach anyway), so maybe some uses would like to start with a specific version.

Yes, that could be an issue.

probably we should offer an option for versioning type dynamic or static

Yes, that would be nice. Right now every backend offers dynamic versioning by default, the only difference being that they do execute functions while obtaining that version from __init__.py.

---

I'd be happy to convert this PR into "static/dynamic" choice PR, or keep this as it is and offer users only "dynamic" versions! :)

[xmnlab]

@Saransh-cpp thanks for the explanation!
I was a bit confused about the name .. dynamic sounds like different than the static ... but according to your explanation for hatch, it is actually static .. but not in the pyproject.toml, is that correct?

if so, in this case it would still be static .. so it looks good to me in general.

but I think that the hard-coded 0.0.1 should be replaced by "{{ cookiecutter.project_version }}", it will be converted to the actual value defined by the user before any hatch run command

[Saransh-cpp]

Yes! Agreed, I will switch to "{{ cookiecutter.project_version }}".

[xmnlab]

thanks for working on that @Saransh-cpp ! LGTM!

[Anavelyz]

@Saransh-cpp Why did you change this?

[xmnlab]

ohhh good catch!! and sorry for my dynamic reading in the review XD
I really need some vacations! I can fix that!

[Saransh-cpp]

Woops, I completely missed that. Thank you for fixing the mess, @xmnlab and @Anavelyz!

[github-actions]

🎉 This PR is included in version 0.5.0 🎉

The release is available on:

• 0.5.0
• GitHub release

Your semantic-release bot 📦🚀