Add testing workflow and use pytest

[smokestacklightnin]

Here is a summary of what is included in this PR:

• As part of this workflow, pytest has been added so that we can drop the previous custom test collection system
• Remove if __name__ == "__main__" section from tests because it is not necessary, or even run, when using pytest. Nontrivial functionality from those sections was preserved.
• Enable INFO level logging in pytest
• Add a github workflow that runs tests. A matrix is used to test multiple Python versions
• Update README.md to reflect changes
• Add xfail mark to classes with failing tests

[peytondmurray]

Wow, the amount of code we save from doing test collection with pytest is big. Just a few comments about the dependencies, otherwise this looks good.

[peytondmurray]

Thanks!

[peytondmurray]

Looks like there are also PicklingErrors - are these related to the problem you mentioned?

[peytondmurray]

After discussion, I'm changing this to a request for changes until we understand the PicklingError.

[smokestacklightnin]

For now, my plan is to add xfail marks to the failing tests to be fixed in the future.

[smokestacklightnin]

Test workflows are passing now that we xfail and skip classes with failing tests

Changes have been made

[iindyk]

this lib is synced from the internal codebase -- the other way does not happen automatically. all the changes will get reverted on the next internal -> github sync. you'd have to make internal change instead

[iindyk]

Do you have access to the internal codebase? If not, you'd have to ask someone with the access to either: 1) port the PR manually and submit it to the internal codebase, or, since I'm assuming this is not the last change you're planning to make, it's better to: 2) configure two-way porting workflow github <-> internal. It would be quite a bit of work since all migration changes will have to be made reversible, but in the long run it will allow submitting from github.

…

On Thu, Sep 12, 2024 at 5:14 PM William Black ***@***.***> wrote: this lib is synced from the internal codebase -- the other way does not happen automatically. all the changes will get reverted on the next internal -> github sync. you'd have to make internal change instead @iindyk <https://github.com/iindyk> What would be the best way to have my and my colleagues' ***@***.*** <https://github.com/peytondmurray>, @aktech <https://github.com/aktech>) merged into the repo? We're from Quansight doing consulting for Google. — Reply to this email directly, view it on GitHub <#315 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFQN6OJ3PEYLJ3T74K22ARLZWIU6PAVCNFSM6AAAAABMTDALIWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBXGQ2DGMZYGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>