Switch to `hatch` for build and (dynamic) versioning

[dhdaines]

You don't actually need to directly use hatch for anything but this gives the option to use it for environment management. Also use its version of setuptools_scm to do dynamic versioning based on Git tags. Also use its plugin for pip-compile to generate a production requirements.txt for Heroku.

So, if you want, you can do:

hatch run dev:check  # runs mypy
hatch run test:test  # runs tests in all python versions
hatch --env dev shell  # gives you a shell with an isolated development environment

But you can also just:

pip install -e .[dev,test]
python run_tests.py all
# etc, etc

[github-actions[bot]]

CLI load time: 0:00.05
PR head 4e23d76b630c54fc8df3a3f4c33efafed7f407f7
Imports that take more than 0.1 s:
import time: self [us] | cumulative | imported package

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 93.59%. Comparing base (b772bd6) to head (4e23d76).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #345 +/- ## ========================================== - Coverage 93.59% 93.59% -0.01% ========================================== Files 18 17 -1 Lines 2342 2341 -1 Branches 520 520 ========================================== - Hits 2192 2191 -1 Misses 85 85 Partials 65 65 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[dhdaines]

Note that to run tests in all of the supported Pythons, you can:

hatch run test:test

Or a single specific version:

hatch run test.py3.7:test

[joanise]

Wow, I just did some digging, and we have never actually directly used requests or dnspython in this repo, and it's been spurious all along! We could have let eventlet declare its own dependency and leave it at that.

The requests dependency was due to a newbie mistake by me: I added import requests in test_cli.py in 2019 but didn't even use it, yet didn't notice that and added it to requirements.txt.

I think dnspython was added to requirements.txt to lock versions, that one did have a valid justification at the time. But it was still always indirect, never a direct dependency.

It's good to clean this stuff up sometimes! Makes me wonder what other dependency declarations we could safely remove... I suppose hatch test doing matrix testing locally helps validate this kind of question, doesn't it?

[joanise]

Not fully reviewed yet, btw, but I've started playing with this. So far I like what I see. I like how the different dependency group declarations are now chained and nicely DRY.

[joanise]

The drop in coverage shown at https://app.codecov.io/gh/roedoejet/g2p/pull/345/commits tells me we need .coveragerc, or maybe just our CI workflow needs it as currently written? We didn't use to calculate coverage on g2p/tests, now we do again with 0347281.

[dhdaines]

The drop in coverage shown at https://app.codecov.io/gh/roedoejet/g2p/pull/345/commits tells me we need .coveragerc, or maybe just our CI workflow needs it as currently written? We didn't use to calculate coverage on g2p/tests, now we do again with 0347281.

Ah, it seems like it was just misconfigured. Should be okay now.

[dhdaines]

Just dropping a reference to https://github.com/juftin/hatch-pip-compile/issues/78 here to explain why g2p[prod] cannot just depend on g2p[api]...

[dhdaines]

Not fully reviewed yet, btw, but I've started playing with this. So far I like what I see. I like how the different dependency group declarations are now chained and nicely DRY.

As you can see there are a couple of bugs (though we are able to work around them) in hatch related to this.

Poetry apparently has more robust, but quite non-standard, support for dependency groups - I do still prefer hatch because of its better environment management and interoperability with other tools (like plain old pip for instance).