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]

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]

Codecov Report

All modified and coverable lines are covered by tests ✅

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

Additional details and impacted files

@@            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              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[joanise]

Hum, there's a lot of stuff I don't get about this PR. We should discuss this one live.

[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 juftin/hatch-pip-compile#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).

[joanise]

Sending the comments I wrote but once again I cannot finish my review today, sorry.

[roedoejet]

This is a lot of work, thanks @dhdaines. The process for installing things on my mac was pretty easy, and I agree it's a lot nicer to maintain interoperability with pip (instead of with poetry). I'm leaving this as a comment for now until we sort out the issue @joanise raised on slack.

[joanise]

OK, finally done my review, and I really like it. I was able to run everything as documented (well, not the hatch-driven matrix test yet, but the rest). With eventlet 0.36.1, tests run and pass. I would declare that dependency as >=0.36.1 now, except for the fact we're about to remove that dependency anyway. So in the mean time I don't care too much.

I'm really looking forward to merging this, I think once AP agree we can go ahead and merge.

[joanise]

In fact, I'm ready to approve this, and we can patch things as needed later.