PYTHON-3958 BSON failure - TestDatetimeConversion.test_millis_from_da…

[NoahStapp]

Resolve by always compiling the C extensions as part of tox -e test, adding about 15-20 seconds to each test run. Is this an acceptable tradeoff for ensuring the C extensions are always up to date?

[ShaneHarvey]

adding about 15-20 seconds to each test run

Is it every test run or only the first time?

[NoahStapp]

adding about 15-20 seconds to each test run

Is it every test run or only the first time?

It's part of tox -e test, so only when that task is run. The various EG tests do not use tox -e test, so their runtime should be unaffected.

[blink1073]

What if we had a script that builds the c ext if the built files don't exist? We could also consider comparing modified times to mimic make

[NoahStapp]

What if we had a script that builds the c ext if the built files don't exist? We could also consider comparing modified times to mimic make

I like these ideas. However, then you can have the situation where you have old C extension files that prevent the rebuild from taking place. Building them on every tox -e test run avoids this issue.

[ShaneHarvey]

Oh I think this is fine then. Personally I don't even use tox -e test at all locally because it's already so slow to setup. Instead I run pytest directly.

[Jibola]

Resolve by always compiling the C extensions as part of tox -e test, adding about 15-20 seconds to each test run. Is this an acceptable tradeoff for ensuring the C extensions are always up to date?

I think it's fine. Do we want to make another step in tox that only compiles the C binary? Or potentially just supply a generalized flag like --rebuild-c-ext that we can supply to every test to run the recompilation on test set up.

Not sure how much of additional scope creep that becomes, but having that as a pre-cursor step would empower autonomy regardless of workflow.

[NoahStapp]

Resolve by always compiling the C extensions as part of tox -e test, adding about 15-20 seconds to each test run. Is this an acceptable tradeoff for ensuring the C extensions are always up to date?

I think it's fine. Do we want to make another step in tox that only compiles the C binary? Or potentially just supply a generalized flag like --rebuild-c-ext that we can supply to every test to run the recompilation on test set up.

Not sure how much of additional scope creep that becomes, but having that as a pre-cursor step would empower autonomy regardless of workflow.

We could make another step for compiling the C extensions, that also gives us a slight amount of abstraction for when we fully migrate away from setuptools.