Error when parenthesis in filename

[zakisaati]

I had an error when executing average_nucleotide_identity.py (ANIb method) which said:
"WARNING: At least one BLAST run failed. ANIb may fail."

I was trying to solve it and finally I found that the problem was related to filenames with parenthesis in it. I removed them and the process worked fine.

I suggest to implement some kind of advise similar to that one that appears when there is a whitespace in filenames.

[widdowquinn]

Thanks @zakisaati - that's a good suggestion. I hadn't realised that parentheses had the same issue as spaces. This is on the list to get a fix.

I'm glad that - otherwise - pyani is working for you.

Cheers,

L.

[baileythegreen]

@widdowquinn I've added in some lines to catch this to average_nucleotide_identity.py on my local version of the version_0_2 branch, but not pushed it yet. I am unsure what the right way to add the changes to the repo are so that they make their way to conda.

[baileythegreen]

Following the check for whitespace, adding this code will catch the error:

        if any(_ in fname for _ in "()"):
            logger.error("File or directory '%s' contains an illegal character, e.g., ( )", fname)
            logger.error("This will cause issues with MUMmer and BLAST")
            logger.error("(exiting)")
            sys.exit(1)

@widdowquinn Please advise on the best way to add this to the code. Attempting to commit from my local branch gives this, and I'm unsure which things need to remain the same for the v2 branch.

[WARNING] The 'rev' field of repo 'https://github.com/ambv/black' appears to be a mutable reference (moving tag / branch).  Mutable references are never updated after first install and are not supported.  See https://pre-commit.com/#using-the-latest-version-for-a-repository for more details.  Hint: `pre-commit autoupdate` often fixes this.
[INFO] Installing environment for https://github.com/ambv/black.
[INFO] Once installed this environment will be reused.
[INFO] This may take a few minutes...
An unexpected error has occurred: CalledProcessError: command: ('..Software/miniconda3/bin/python', '-mvirtualenv', '../.cache/pre-commit/repoonvsa2bi/py_env-python3.6', '-p', 'python3.6')
return code: 1
expected return code: 0
stdout:
    RuntimeError: failed to find interpreter for Builtin discover of python_spec='python3.6'
    
stderr: (none)
Check the log at ../.cache/pre-commit/pre-commit.log

[widdowquinn]

@baileythegreen Looks like a local configuration issue - most likely with pre-commit. Have you tried the hint that was suggested?

Hint: `pre-commit autoupdate` often fixes this.

[widdowquinn]

FWIW I think that a function to identify and/or escape paths that are not tolerated by nucmer would be useful, here. pyani_tools or anim would both be reasonable homes for that sort of thing, IMO.

[baileythegreen]

Looks like a local configuration issue - most likely with pre-commit. Have you tried the hint that was suggested?

I have; that maybe works, but then I get this error:

Cannot update because the update target is missing these hooks:
flake8

I've tried updating the .pre-commit-config-yaml file to fix it, but it's a domino sequence of new errors; at the moment, I think it is complaining that I don't have python 3.6 installed.

[widdowquinn]

I have occasionally seen this issue.

Cannot update because the update target is missing these hooks:
flake8

IIRC the last time I encountered it, that was because the flake8 hook is no longer part of pre-commit, and the recommended way to include flake8 AIUI is now to incorporate it straight from its own repo. I would expect the master branch config file to work, so if you're not on that branch right now you may wish to rebase. If it's that config file that's giving the problem, then some investigation is needed.

[baileythegreen]

I'm not on master because this issue only applies to the v2 version of bin/average_nucleotide_identity.py so far as I've seen. There at least isn't a check for whitespace in the file names in v3's version of the same file.

I wouldn't think rebasing from master was the best idea for this particular branch. It's the v2 branch, and therefore doesn't have MANY of the things v3 does; at the very least, rebasing means polluting the branch with lots of files v2 doesn't use.

[widdowquinn]

I had not realised that this issue applied exclusively to v0.2 - that's not clear from the thread. And yes, when you're working on the v0.2 branch then rebasing to v0.3 does not make sense.

You could still git checkout the pre-commit config file from that branch in isolation, or implement the fix in that file which is noted above.

[baileythegreen]

I had not realised that this issue applied exclusively to v0.2 - that's not clear from the thread.

True. I remember it did take me a while to find the relevant place in the code.

or implement the fix in that file which is noted above.

Apparently I had already done this before, when I realised I couldn't commit the changes easily.

I do not think this issue should be closed before the change is present on conda.

[widdowquinn]

I do not think this issue should be closed before the change is present on conda.

Which change? The pre-commit/flake8 issue is a development issue and irrelevant for the conda distribution IMO. The actual topic of this issue - that some filename formats are not well-processed - should absolutely be fixed before the issue is closed.

Note for future handling of issues: the tangent into local configuration of flake8/pre-commit is unrelated to the title of the thread and better handled in its own issue, or by a different communication channel. This particular issue could have been sorted out quickly with a short conversation.

[baileythegreen]

I do not think this issue should be closed before the change is present on conda.

Which change?

The one checking for the parentheses. Just stating why I was not closing the issue yet, even though code is in place in the repo to resolve it.

I've added a discussion about the correct way to upload to PyPI—as I believe this is how the code will make its way to conda—here: #395.

[widdowquinn]

Which change?

The one checking for the parentheses.

My general view is that we can close bug fixes when the bug is fixed, and we do not need to leave them open until a release.

If we want to tie issues to a release (so, for instance, we can record how far short of a release we are, or note which issues are associated with a release) then we may be better using the Milestones functionality of GitHub projects. That would be my preference.

[baileythegreen]

As per @widdowquinn's comment, I am closing this and adding this issue to a milestone for inclusion in a new release of v2.

[baileythegreen]

@all-contributors please add @zakisaati for bug

[allcontributors]

@baileythegreen

I've put up a pull request to add @zakisaati! 🎉