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

Untested code in fastani.py #405

Open
baileythegreen opened this issue Jun 29, 2022 · 1 comment · May be fixed by #409
Open

Untested code in fastani.py #405

baileythegreen opened this issue Jun 29, 2022 · 1 comment · May be fixed by #409
Labels
VERSION_3 issues relating to version 0.3.x of pyani

Comments

@baileythegreen
Copy link
Contributor

Summary:

Lines 97–99 in pyani/fastani.py:

    if fastani_path is None:
        return f"{fastani_exe} is not found in $PATH"

are missed by testing, and likely redundant. fastani_path is defined a few lines before, within a try/except block; were this to raise something other than a TypeError (thus leaving fastani_path unassigned), which is handled with a logging statement, the program would still exit before lines 97–99 were run.

Commenting out these lines causes no tests to fail. Whereas commenting out lines 93–96, causes test_get_version_nonetype() from pyani/tests/test_fastani.py to fail.

pyani Version:

pyani version: 0.3.0-alpha

installed dependencies

If you are running a version of pyani v0.3 or later, then please run the command pyani listdeps at the command line, and enter the output below.

Python Version:

3.8.12

Operating System:

macOS High Sierra

@baileythegreen baileythegreen added the VERSION_3 issues relating to version 0.3.x of pyani label Jun 29, 2022
@baileythegreen
Copy link
Contributor Author

baileythegreen commented Jul 22, 2022

Upon further investigation, the flagged lines are redundant, sort of.

shutil.which(None) # --> returns a TypeError
shutil.which("any string that is not a valid PATH") # --> returns None
Path(None) # --> returns a TypeErorr

So, the try/except block catches two different cases that both trigger the same line. This both seems efficient, and like a potential point of confusion, so I am unsure of the most desirable way to resolve the code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
VERSION_3 issues relating to version 0.3.x of pyani
Projects
None yet
1 participant