Skip to content

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants