Closed JoshMock closed 1 year ago
@pquentin Good points! And all things I was hoping to uncover by opening a draft PR.
I'm more than happy to keep things in Nox. I really like how Hatch manages envs and their dependencies, but it's more of a convenience than a necessity.
Part of the inspiration here was that elasticsearch-py has an open issue where Seth seconded the use of Hatch to help migrate away from setup.py. But your point about just using Hatchling for packaging strikes a nice balance. I'll see about shifting back that direction.
@pquentin cleaned things up a bit. what do you think?
I kept Hatch as a dependency for version bumping and build targets, but I assume I could drop tool.hatch.version
and tool.hatch.build.targets.sdist
from the config if you only wanted to use hatchling.
Actually I just talked myself out of tool.hatch.version
. We won't really need to automate versioning of this package since it will not need to stay in sync with the ES stack version.
Of course! Thanks for all the useful feedback @pquentin. First time migrating from a setup.py. :smile:
I used Hatch to convert
setup.py
intopyproject.toml
, and then did some cleanup to drop dev-requirements.txt, ensurenox
scripts keep running, etc.