Skip to content

Use hatch-vcs for dynamic version#17

Merged
eriknw merged 2 commits intoscientific-python:mainfrom
eriknw:hatch_vcs
Jul 23, 2025
Merged

Use hatch-vcs for dynamic version#17
eriknw merged 2 commits intoscientific-python:mainfrom
eriknw:hatch_vcs

Conversation

@eriknw
Copy link
Contributor

@eriknw eriknw commented Jul 22, 2025

This minimally adds dynamic package version using hatch-vcs, which I saw was already included in [build-system] of pyproject.toml. The dev version will be silly until we tag a release.

I also warn if the package may not be installed properly. I like doing this, and I don't know if there's a better, builtin way to do this. When entry-points are involved, it's important that packages be installed so that entry-points may be found.

I'm tool-agnostic and don't have a strong opinion about hatch or others.

Copy link
Contributor

@seberg seberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have an opinion on tooling. I got the hatch, based on the cutter template for no particular reason.
EDIT: I suppose there may be a time where we want a small extension module helper, and then tooling may need to drift a bit, but that doesn't matter yet.

Logic seems good to me (not sure if this is a recipe or not).

@eriknw feel free to push on here if you like. Not sure how the vcs works, but I would think we could just tag the initial commit or so as 0.0.0dev or so?

@eriknw
Copy link
Contributor Author

eriknw commented Jul 23, 2025

Thanks for looking @seberg.

Yeah, tooling can always change, and I don't mind learning more about hatch. I'm going to go ahead and merge.

I tagged the initial commit 0.0.0dev0.

@eriknw eriknw merged commit 2583740 into scientific-python:main Jul 23, 2025
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants