[Python-Dev] Tests failing on Windows with TESTFN
On Mon, Jul 30, 2018 at 8:46 AM, Tim Golden <mail at timgolden.me.uk> wrote:
> On 30/07/2018 16:41, Nick Coghlan wrote:
>> On 29 July 2018 at 03:20, Tim Golden <mail at timgolden.me.uk> wrote:
>>> I think that was my starting point: rather than develop increasingly
>>> involved and still somewhat brittle mechanisms, why not do what you'd
>>> naturally do with a new test and use tempfile? I was expecting someone to
>>> come forward to highlight some particular reason why the TESTFN approach
>>> superior, but apart from a reference to the possibly cost of creating a
>>> temporary file per test, no-one really has.
>> For higher level modules, "just use tempfile to create a new temporary
>> directory, then unlink it at the end" is typically going to be a good
>> answer (modulo the current cleanup issues that Jeremy is reporting,
>> but ideally those will be fixed rather than avoided, either by
>> improving the way the module is being used, or fixing any underlying
If there's a desire to use tempfile, another option is to have
tempfile create the temp files inside the temporary directory the test
harness creates specifically for testing -- using the "dir" argument
to many of tempfile's functions.
Here is where the process-specific temp directory is created for
testing (inside test.libregrtest.main):
This would also facilitate the clean-up of any leftover temp files.
Again, I think it would be best to use any tempfile functions behind
one or more test-support functions, so the choice of location, etc.
can be changed centrally without needing to modify code everywhere.
>> For lower level modules though, adding a test suite dependency on
>> tempfile introduces a non-trivial chance of adding an operational
>> dependency from a module's test suite back to the module itself. When
>> that happens, module regressions may show up as secondary failures in
>> tempfile that then need to be debugged, rather than as specific unit
>> test failures that point you towards exactly what you broke.
> Thanks Nick; I hadn't thought about the possible interdependency issue.
> I think for the moment my approach will be to switch to support.unlink
> wherever possible to start with. Before introducing other (eg tempfile)
> changes, this should at least narrow the issues down. I've made a start on
> that (before inadvertently blowing away all the changes since my
> hours-previous commit!)
> If further changes are necessary then I'll probably look case-by-case to see
> whether a tempfile or some other solution would help.
> That said, that's potentially quite a lot of change -- at least in terms of
> files changed if not strictly of functionality. So I'm thinking of
> trickle-feeding the changes through as people will understandably baulk at a
> patchbomb (PR-bomb?) hitting the codebase all at once.
> Python-Dev mailing list
> Python-Dev at python.org