GitHub Actions & Dev Tools Cleanup + Python 3.11 Support

[bmos]

I'm not really sure how these changes could be merged nicely with other open PRs.
I'm happy to restructure it however is desired, so perhaps treat this as a sort of menu.

What's Included

• Simplified the linting workflow to use a single file for both mac and linux testing.
• Use the rust-based package installer uv to significantly reduce the GitHub actions runtime to allow a second python version in macOS testing.
• Functionalized __init__.py (which is kind of pointless but I did it while debugging an error I was getting) and fixed a typo in it (one of the tuples was a list instead).
• Fix import of HttpError in gmail.py (which for some reason your pytest workflow was not catching).
• Updated packages that were needed to get pytest to pass or were missing patch-level updates.
• Restructured limited dependencies mode to use the same dependency versions as the usual install.
• Resolve the TypeError raised when running pytest under Python 3.11. Required upstream fix.
• Flake8 was set to maintain a 100 character max line length, but Black didn't have a line length option configured which meant it was defaulting to a much lower 88. These are now both 100.
• Add flake8, pytest, and black configurations to pyproject.toml rather than having a mix of separate config files and command-line args -- also standardized the commands used in all places.
• Updated Black and Flake8 to latest versions and applied their updated linting suggestions.
• Pytest now finishes with 3 warnings instead of 13.

Notes / Considerations

• Removed support for python 3.7 as it is not supported with uv. This could be added back as a supported version along with its own test workflow or no test workflow, if preferred. I know dropping 3.7 was recently discussed in Documentation discrepancy regarding supported Python versions #932.
• Closes [Bug] Parsons 3.1.0 targets yanked 4.0.0 version of braintree with critical bugs #1007 by using a version of braintree that has not been yanked

[austinweisgrau]

I think this should be split into several different PRs for the different components here. Each PR should explain the motivation for the relevant changes and what is affected.

I see these as separate PR scopes:

• linting changes
• CICD changes
• package management changes
• 3.11 compatibility
• bug fixes

[austinweisgrau]

Good work though, these look mostly like nice updates. I think we'd want to discuss pros and cons of switching to uv, and I think it would be preferable to stick to the black line length default of 88 rather than switching it to the flake8 default of 100, but we should have those discussions in smaller scoped PRs.

Another note is to make sure that any PRs with breaking changes are set up to merge into the major-release branch rather than main. Mostly looking at the dropping support for 3.7.

[bmos]

Thanks for those notes, I will restructure this into the suggested categories.

I think it would be preferable to stick to the black line length default of 88 rather than switching it to the flake8 default of 100

100 is not the default for flake8, that would be 79.
I went with 100 because the flake8 config file in your repo says 100 and the CONTRIBUTING.md file also includes it in the flake8 command. If 88 is the desired value I can change those values of 100 to 88 -- standardization was my goal, not a longer line length.

[austinweisgrau]

Thanks for those notes, I will restructure this into the suggested categories.

I think it would be preferable to stick to the black line length default of 88 rather than switching it to the flake8 default of 100

100 is not the default for flake8, that would be 79. I went with 100 because the flake8 config file in your repo says 100 and the CONTRIBUTING.md file also includes it in the flake8 command. If 88 is the desired value I can change those values of 100 to 88 -- standardization was my goal, not a longer line length.

Oh word gotcha that makes sense! Yeah I think maintaining whatever the documented value is makes the most sense so that sounds right to me.

[bmos]

Does the major release branch need to be brought up to main?

[austinweisgrau]

It doth, yes. It will be eventually, PRs against it will look a little messy until that happens.

…

On Wed, Mar 13, 2024, 8:06 PM Wil T ***@***.***> wrote: Does the major release branch need to be brought up to main? — Reply to this email directly, view it on GitHub <#1009 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AO74QHX3ZANUFFE4Y337AFDYYEH4BAVCNFSM6AAAAABES6PVC2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJWGMYDOMZRHE> . You are receiving this because you commented.Message ID: ***@***.***>