-
Notifications
You must be signed in to change notification settings - Fork 2
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
Tests failing on AppVeyor #627
Comments
Noticed on #625. |
See issue #627, this part of the test has started to fail on AppVeyor
See issue #627, this part of the test has started to fail on AppVeyor
See issue #627, this part of the test has started to fail on AppVeyor
See issue #627, this part of the test has started to fail on AppVeyor
Time frame for an AppVeyor related change in 22 May to 3 June... There have been updates to cutadapt 4.8 on bioconda, but should by from PyPI via pip - and no changes there since April 2024. |
Looks like the cutadapt call is failing, generated file Bad: Good: Surely not due to a point revision of typing-exensions? |
Closes #627 where this was failing on AppVeyor (unclear why)
Interesting, fixing that test by pre-generating the FASTA file, it now fails on another cutadapt piping example:
|
This reminds me of marcelm/cutadapt#774 which was traced to a problem in xopen 2.0.0 pycompression/xopen#157 But it is different, the AppVeyor failures are using xopen-2.0.1-py3-none-any.whl I note cutadapt 4.8 does use typing_extensions to define a sequence protocol, https://github.com/marcelm/cutadapt/blob/v4.8/src/cutadapt/qualtrim.pyi Test case working locally but under Python 3.10 not 3.12:
|
Couldn't reproduce this on Linux with Python 3.11.6 either, but given I suspect the typing extensions Python 3.12 might be key here. |
Not typing-extensions 4.12.2, this faild on AppVeyor:
|
Trying locally with Python 3.12.3 to match AppVeyor, and using the current master branch:
Hmm. Works here too - what is different under AppVeyor? |
I think I need to try and run this locally under Windows... |
Note since then xopen v2.0.2 (2024-06-12) was released but did not makeany differnce to this issue with AppVeyor. |
I ran your tests in a Windows 10 virtual machine that I keep around for these kinds of things, but could not reproduce your problem. I’m sure I didn’t fully reproduce what AppVeyor does (and my Windows knowledge is too limited), though. I’m wondering whether this is an encoding issue. This message that Cutadapt prints
comes from detect_file_format. In this case, it means that the first character read from stdin was not a Also, one of the later tests fails like this:
Note the question mark instead of the gamma character in the error message (and alpha became a regular a). This may be independent, but it at least gave me the idea that some encoding thing is going on. Oh, and maybe as a workaround, you could avoid running two Cutadapt processes connected by a pipe. Instead of trimming the two primers in two steps, you can use a linked adapter. Instead of
you would use
I’ll also make the |
Thank you. Good guess on the BOM, but no:
I was able to get Your idea about the encoding seems more likely. That would certainly explain the alpha or gamma switch failing (they have plain ASCII alias too, I add the symbolic argument partly to see how well supported it would be - it seemed to be working nicely cross platform but I guess there are still corner cases). |
I first tried installing Python 3.12 from the Microsoft Store, but while
Minimal test case using filename as input works:
Changed to pipe file via stdin, fails:
Updated the latest cutadapt Python files from git (copied over the installed v4.9 ones, I don't have MSVC etc installed):
That seems to be from the second to last sequence in the file (Uncultured Peronosporaceae clone MZOo17), i.e. the start of the stdin appears to get lost somewhere - perhaps linked to why detection is called twice?
Here I inserted this into the start of the detect_file_format function: import sys
sys.stderr.write(f"detect_file_format {file.seekable()}, {file.tell()}, {file.peek(4)[0:4]}\n") P.S. This is on Windows 11 |
See #627 where this had started to fail on AppVeyor on Windows (something to do with piping support changing).
This should sidestep the currently unexplained regression with cutadapt on Windows not handling stdin any more (isse #627).
See #627 where this had started to fail on AppVeyor on Windows (something to do with piping support changing).
This should sidestep the currently unexplained regression with cutadapt on Windows not handling stdin any more (isse #627).
They may be failing on CircleCI too, but masked by #626. Tests failing:
No obvious cause in the code itself, perhaps a platform change? Before/after were both using cutadapt 4.8
The text was updated successfully, but these errors were encountered: