On Mon, Jul 30, 2018 at 8:46 AM, Tim Golden wrote:
> On 30/07/2018 16:41, Nick Coghlan wrote:
>>
>> On 29 July 2018 at 03:20, Tim Golden wrote:
>>>
>>> I think that was my starting point: rather than develop increasingly
>>> involved and still somewhat brittle mechanisms, why not do what you'd
On 30/07/2018 16:41, Nick Coghlan wrote:
On 29 July 2018 at 03:20, Tim Golden 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
On 29 July 2018 at 03:20, Tim Golden 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
: eryk sun
Sent: Sunday, 29 July 2018 15:28
To: python-dev@python.org
Subject: Re: [Python-Dev] Tests failing on Windows with TESTFN
On Sun, Jul 29, 2018 at 12:35 PM, Steve Dower wrote:
>
> One additional thing that may help (if support.unlink doesn't already do it)
> is to rename the fi
On Sun, Jul 29, 2018 at 9:34 AM Tim Golden wrote:
> For test_mailbox I've experimentally implemented a hybrid tempfile /
> local directory solution. ie I've created a new file on each run, but
> only within the python_ folder which already exists. As long as the
> directory cleans up there should
On 29/07/2018 15:21, Jeremy Kloth wrote:
On Sun, Jul 29, 2018 at 3:13 AM Tim Golden wrote:
For an example:
http://tjg.org.uk/test.log
Thank you! After inspecting all the errors, it does seem that they
are ALL caused by "bare" os.unlink/rmdir calls. So it seems that a
massive undertaking
On Sun, Jul 29, 2018 at 2:21 PM, Jeremy Kloth wrote:
>
> try:
> os.rename(new_file.name, self._path)
> except FileExistsError:
> -os.remove(self._path)
> +temp_name = _create_temporary_name(self._path)
> +os.rename(self._path,
On Sun, Jul 29, 2018 at 12:35 PM, Steve Dower wrote:
>
> One additional thing that may help (if support.unlink doesn't already do it)
> is to rename the file before deleting it. Renames are always possible even
> with open handles, and then you can create a new file at the original name.
On Sun, Jul 29, 2018 at 3:13 AM Tim Golden wrote:
> For an example:
>
> http://tjg.org.uk/test.log
Thank you! After inspecting all the errors, it does seem that they
are ALL caused by "bare" os.unlink/rmdir calls. So it seems that a
massive undertaking of ferreting out these locations and
On Sun, Jul 29, 2018 at 9:13 AM, Tim Golden wrote:
>
> For an example:
>
> http://tjg.org.uk/test.log
>
> Thinkpad T420, 4Gb, i5, SSD
>
> Recently rebuilt and reinstalled: Win10, VS2017, TortoiseGit, standard
> Windows Antimalware, usual developer tools. That particular run was done
> with the
On 29Jul2018 0958, Tim Golden wrote:
In the interests of trying to keep a focus to the changes I'm making, I
propose to start again by, as you suggest, making use of
test.support.unlink where it's not currently used. From the evidence I
don't believe that will solve every problem I'm seeing
On 28/07/2018 22:17, Jeremy Kloth wrote:
On Sat, Jul 28, 2018 at 11:20 AM Tim Golden wrote:
Although things have moved on since that discussion and
test.support.unlink has grown some extra legs, all it's done really is
to push the bump along the carpet for a bit. I've got a newly-installed
On 29/07/2018 02:04, Jeremy Kloth wrote:
On Sat, Jul 28, 2018 at 6:43 PM Brett Cannon
wrote:
If Windows doesn't clean up its temp directory on a regular basis
then that doesn't suggest to me not to use tempfile, but instead
that the use of tempfile still needs to clean up after itself. And
if
On Sat, Jul 28, 2018 at 7:15 PM Chris Jerdonek wrote:
> Regardless of whether the tempfile or TESTFN approach is used, I think it
> would be best for a few reasons if the choice is abstracted behind a uniquely
> named test function (e.g. make_test_file if not already used).
+1, although my
On Sat, Jul 28, 2018 at 5:40 PM Brett Cannon wrote:
>
> On Sat, Jul 28, 2018, 15:13 eryk sun, wrote:
>
>> On Sat, Jul 28, 2018 at 9:17 PM, Jeremy Kloth
>> wrote:
>> >
>> > *PLEASE*, don't use tempfile to create files/directories in tests. It
>> > is unfriendly to (Windows) buildbots. The
On Sat, Jul 28, 2018 at 6:43 PM Brett Cannon wrote:
> If Windows doesn't clean up its temp directory on a regular basis then that
> doesn't suggest to me not to use tempfile, but instead that the use of
> tempfile still needs to clean up after itself. And if there is a lacking
> feature in
On Sat, Jul 28, 2018, 15:13 eryk sun, wrote:
> On Sat, Jul 28, 2018 at 9:17 PM, Jeremy Kloth
> wrote:
> >
> > *PLEASE*, don't use tempfile to create files/directories in tests. It
> > is unfriendly to (Windows) buildbots. The current approach of
> > directory-per-process ensures no test turds
On Sat, Jul 28, 2018 at 9:17 PM, Jeremy Kloth wrote:
>
> *PLEASE*, don't use tempfile to create files/directories in tests. It
> is unfriendly to (Windows) buildbots. The current approach of
> directory-per-process ensures no test turds are left behind, whereas
> the tempfile solution slowly
On Sat, Jul 28, 2018 at 5:20 PM, Tim Golden wrote:
>
> I've got a mixture of Permission (winerror 13) & Access errors (winerror 5)
EACCES (13) is a CRT errno value. Python raises PermissionError for
EACCES and EPERM (1, not used). It also does the reverse mapping for
WinAPI calls, so
On Sat, Jul 28, 2018 at 10:20 AM, Tim Golden wrote:
>
> Here's the thing. The TESTFN approach creates a directory per process
> test_python_ and some variant of @test__tmp inside that directory.
I filed an issue some years back about this (still open):
https://bugs.python.org/issue15305
The pid
On Sat, Jul 28, 2018 at 11:20 AM Tim Golden wrote:
> Although things have moved on since that discussion and
> test.support.unlink has grown some extra legs, all it's done really is
> to push the bump along the carpet for a bit. I've got a newly-installed
> Win10 machine with the typical MS
On 28/07/2018 17:27, Jeremy Kloth wrote:
On Sat, Jul 28, 2018 at 8:41 AM Tim Golden wrote:
1) Why are these errors occurring? ie are we dodging a root cause issue
The root cause is how Windows handles file deletions. When a file is
removed, it is not immediately removed from the directory,
On Sat, Jul 28, 2018 at 8:41 AM Tim Golden wrote:
> 1) Why are these errors occurring? ie are we dodging a root cause issue
The root cause is how Windows handles file deletions. When a file is
removed, it is not immediately removed from the directory, instead, it
is simply marked for deletion.
On 25/07/2018 16:07, Tim Golden wrote:
One problem is that certain tests use support.TESTFN (a local directory
constructed from the pid) for output files etc. However this can cause
issues on Windows when recreating the folders / files for multiple
tests, especially when running in parallel.
On Fri, Jul 27, 2018 at 4:48 PM Chris Jerdonek wrote:
>
> On Fri, Jul 27, 2018 at 6:41 AM, Giampaolo Rodola' wrote:
> >
> > Being TESTFN a global name it appears not suited for parallel testing.
>
> It was designed for parallel testing though:
>
> # Disambiguate TESTFN for parallel testing,
On Fri, Jul 27, 2018 at 6:41 AM, Giampaolo Rodola' wrote:
>
> Being TESTFN a global name it appears not suited for parallel testing.
It was designed for parallel testing though:
# Disambiguate TESTFN for parallel testing, while letting it remain a valid
# module name.
TESTFN =
On Thu, Jul 26, 2018 at 12:16 AM Tim Golden wrote:
>
> I'm just easing back into core development work by trying to get a
> stable testing environment for Python development on Windows.
>
> One problem is that certain tests use support.TESTFN (a local directory
> constructed from the pid) for
On Wed, Jul 25, 2018 at 8:07 AM, Tim Golden wrote:
> One problem is that certain tests use support.TESTFN (a local directory
> constructed from the pid) for output files etc. However this can cause
> issues on Windows when recreating the folders / files for multiple tests,
> especially when
On Wed, 25 Jul 2018 at 15:16 Tim Golden wrote:
> I'm just easing back into core development work by trying to get a
> stable testing environment for Python development on Windows.
>
> One problem is that certain tests use support.TESTFN (a local directory
> constructed from the pid) for output
[trying again; sorry if it shows up twice]
I'm just easing back into core development work by trying to get a
stable testing environment for Python development on Windows.
One problem is that certain tests use support.TESTFN (a local directory
constructed from the pid) for output files etc.
I'm just easing back into core development work by trying to get a
stable testing environment for Python development on Windows.
One problem is that certain tests use support.TESTFN (a local directory
constructed from the pid) for output files etc. However this can cause
issues on Windows
31 matches
Mail list logo
