Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix windows #157

Merged
merged 15 commits into from
Nov 9, 2017
Merged

Fix windows #157

merged 15 commits into from
Nov 9, 2017

Conversation

nicoddemus
Copy link
Member

Trying to make the Windows CI work again.

@nicoddemus
Copy link
Member Author

Had to skip a lot of tests on Windows to get the suite to pass: #161 and #162. Also skipping one of the tests which was failing under xdist (#160).

I want to have the suite passing on Windows specially for the parts which are still used by pytest: for example, the "x" flag being passed to py.path would break pytest on Windows immediately upon release.

def create_lockfile(path):
""" exclusively create lockfile. Throws when failed """
mypid = os.getpid()
lockfile = path.join('.lock')
if hasattr(lockfile, 'mksymlinkto'):
lockfile.mksymlinkto(str(mypid))
else:
lockfile.write(str(mypid), 'wx')
lockfile.write(str(mypid), 'w' + exclusive_flag)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as far as i can tell without the exclusive flag the lockfile creation is broken

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what to do here, because passing wx to lockfile.write raises an exception on Windows:

ValueError: must have exactly one of create/read/write/append mode

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, it is problematic then that removing this flag didn't break any test. Either it is not necessary or we are not covering the case where the flag is needed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the x flag is absolutely critical as it ensures exclusive open - else the operation wont fail if the element exists

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the x flag is absolutely critical as it ensures exclusive open - else the operation wont fail if the element exists

I got that. 😄 It is still a problem that no test breaks on Windows after the flag has been removed.

Just to be clear: Windows does not support the x flag so we can't publish 1.5 with this change otherwise we will break every new pytest installation where the test suite uses tmpdir.

How should we proceed?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i ccd you in the relevant pr

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Let's move the discussion there then.

@@ -5,6 +5,13 @@
from py._path import svnwc as svncommon
from svntestbase import CommonSvnTests


@pytest.fixture(autouse=True)
def skip_on_windows():
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just use a mark?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Duh don't know what I was thinking. Thanks!

Due to known mark transfer problems, the global pytestmark ends up
overwriting the mark which was originally applied to this test
def test_status_update(self, path1):
# not a mark because the global "pytestmark" will end up overwriting a mark here
pytest.xfail("svn-1.7 has buggy 'status --xml' output")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is fixed in recent pytest and should be in the next feature release (the evaluator refactoring)

@nicoddemus
Copy link
Member Author

Pushed a new commit with the file locking fix for Windows as suggested by @aurzenligl in #143, kudos to him. 👍

@@ -446,13 +453,6 @@ def notimpl(x, y):
assert x.relto(tmpdir)
assert x.check()

def test_make_numbered_dir_multiprocess_safe(self, tmpdir):
Copy link
Member Author

@nicoddemus nicoddemus Nov 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason why this test was not catching the regression in the previous locking code for Windows is that it was being skipped on Windows (this class has the pytestmark = skiponwin32 mark).

def create_lockfile(path):
""" exclusively create lockfile. Throws when failed """
mypid = os.getpid()
lockfile = path.join('.lock')
if hasattr(lockfile, 'mksymlinkto'):
lockfile.mksymlinkto(str(mypid))
else:
lockfile.write(str(mypid), 'w' + exclusive_flag)
try:
fd = os.open(str(lockfile), os.O_WRONLY | os.O_CREAT | os.O_EXCL, 0o644)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use py.error.checked_call here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

main reason is to account for all the other errors that could unexpectedly happen

@nicoddemus
Copy link
Member Author

I'm hitting this bug when running on Python 2.6 on Windows:

AssertionError    prepare(preparation_data)
  File "D:\Programming\Python26\Lib\multiprocessing\forking.py", line 449, in prepare
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "D:\Programming\Python26\Lib\multiprocessing\forking.py", line 341, in main
:     _assert main_name not in sys.modules, main_name
Traceback (most recent call last):
_main__AssertionError:
  File "<string>", line 1, in <module>
    _prepare(preparation_data)
_main__
  File "D:\Programming\Python26\Lib\multiprocessing\forking.py", line 449, in prepare
  File "D:\Programming\Python26\Lib\multiprocessing\forking.py", line 341, in main
        assert main_name not in sys.modules, main_name
prepare(preparation_data)
AssertionError  File "D:\Programming\Python26\Lib\multiprocessing\forking.py", line 449, in prepare
: _    _main__assert main_name not in sys.modules, main_name

AssertionError: __main__

This is the reason why the py26 environments are all timing out.

I could trace it to this bug which has been fixed in Python 2.7.11. The bug is related to the fact that Windows does not have fork functionality.

My suggestion is to just skip that test in Python 2.6 and Windows for now, given that we plan to remove 2.6 and 3.3 support soon anyway (#159).

@RonnyPfannschmidt
Copy link
Member

i agree

@nicoddemus nicoddemus merged commit e5f9547 into pytest-dev:master Nov 9, 2017
@nicoddemus nicoddemus deleted the fix-windows branch November 9, 2017 20:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants