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
[ENH] make as many tox tests work under windows as possible #347
Comments
The approach is rather simple, even if perhaps tedious:
My suggestion would be to first comment out all tests and then uncomment them step by step, making a Pull Request for each few steps in order to avoid having one big PR at the end with a major review, while still having value to each PR. Feel free to create a "draft/WIP" PR if you need help, it makes review and discussion around the code rather easy. |
So far I'm stumbling into some issues where some bytes APIs don't work on Windows and/or some APIs don't accept bytes, etc. For example in
So now I'm working my way through just changing some things one by one to try and get more and more working. But in parallel (as not a very experienced Python developer) I would like to enquire why bytes types are used rather than strings, so that I won't go changing them all to strings in places where it's not appropriate? |
I have addressed a few baby steps in #444. I can continue to address more and more, but as a next step I will try to fix up the Unfortunately I was unable to set up vagrant properly on my Linux machine (Ubuntu 18.04 LTS) and I don't want to go through all the effort of setting up all the Ansible stuff on my Windows environment (on which Docker won't run anyway, because it's in a VirtualBox VM). So I cannot verify anything using the automated tests on Windows so will continue to keep doing it manually using I already foresee a lot of problems with the usage of bytes types all over the place, though. It looks like a bunch of Python APIs using bytes are not available on Windows, only offering one with strings. As I mentioned in a comment above I don't really understand why bytes are used instead of strings, so I want to understand that first before I start changing those instances with strings. Another point I could already identify but not yet address is |
Good approach, I'm supporting it and reviewed the PR. We have an issue with Travis CI but we'll get it fixed. Small hint: have a look at the @unittest.skipXXX decorators to avoid spending too much time on tests which can not be run on Windows (something like
OK, I can help on setting up Vagrant but it can indeed be a beast.
It's a longer story, I'll try to make it short:
I'm a bit short in time but we're aware of the issue and are in discussion with @dbaarda, the maintainer of librsync about this. Check #67 and #207. Don't expect an easy/quick fix hence. |
Sorry, I can't remember having closed the issue so I think I've just pressed the wrong button. The approach agreed previously is still valid, no issue. Sorry for the confusion. Re-opening. |
* making tox work under Windows * #347: tox_win: commented failing tests and included deps * statisticstest also runs fine on Windows
@t9t I tried to make tox_win.ini working under Windows but it fails on the statistics test, does it ring a bell to you? Same code version works under Linux...
|
One small step towards understanding the above issue: it doesn't have anything to do with the tox setup, I can reproduce outside of the tox "cage". |
It has even nothing to do with the testcase, I can reproduce the issue with the following snippet under Windows:
Or vice-versa, no difference: the first call succeeds, the 2nd one fails. |
I moved the specific problem to a specific issue... let's focus here further on the test cases. |
Before my absence, I ran each test individually to see what worked (and could uncomment in #447) and what didn't work yet and why. Broadly, the following issues exist:
There are also plenty of tests which failed where I wasn't able to identify the cause of the failure at first glance. It could even be that in some cases the test was actually working fine, but there might have been a bug in the code. Unfortunately, I had quite a hard time reading and understanding the actual rdiff-backup application code. And I must confess that this is also the point where I lost some motivation to work on this (this was also the moment when I realised that in fact I'm not such a big fan of Python at all 😂). I think the most interesting next step for now is to figure out what to do with the tests that call |
Hence I start to answer this one: I think I have already fixed the issue in my Vagrant setup. Just create a file called @ECHO OFF
REM simple wrapper script to call rdiff-backup from the repo
REM d=Disk, p=(dir)path, n=name(without extension), x=extension
python "%~dpn0" %* The trick here is that Windows finds After that, you can follow different courses of action, or a mixture of those:
I'd personally, but it really depends on how you prefer to work, start with skipping (and hence identifying) all failing tests with decorators, either intelligently if the reason is obvious, or stupidly if it's too complicated. That could easily be a the subject of a single MR, because it'll be easy to review, only addition of decorators before failing test functions. Then, in a second pass, test script after test script, remove the skipping decorators and make more and more tests work under Windows. Does it make sense? Does it help? Reference: https://docs.python.org/3/library/unittest.html#skipping-tests-and-expected-failures |
Is your feature request related to a problem? Please describe.
We don't have a test suite under Windows and this has led to regressions in the move from 1.2/1.3 to 2.0 and might lead again to regressions. Not all the tests can work, but most should work.
Describe the solution you'd like
I've started a branch https://github.com/rdiff-backup/rdiff-backup/tree/ericzolf-make-tox-work-under-win but it requires more work and I fear much more work, so if someone wants to take over, be my guest!
The text was updated successfully, but these errors were encountered: