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

Altered if clasuses around selection of commands in umi_tools.py #537

Merged
merged 6 commits into from
Sep 26, 2022

Conversation

IanSudbery
Copy link
Member

Fixes (or at least starts to fix) #536

@TomSmithCGAT Bit confused as to what is going on in the umi_tools module. Specifically what the original purpose of the if clause at lines 51-52 was.

I've also made each tool print its usage message if no options are passed at all. Don't know if this was the right was to do this, or if I should have done something more central (although that would become a problem if there was a tool that could be run without options. Which currently there isn't).

@IanSudbery IanSudbery requested a review from TomSmithCGAT June 5, 2022 17:34
@@ -1030,7 +1030,7 @@ def Start(parser=None,

if return_parser:
return parser

Copy link
Member

Choose a reason for hiding this comment

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

Is that just a tab added?

@@ -86,12 +86,17 @@ def main(argv=None):

if argv is None:
argv = sys.argv

Copy link
Member

Choose a reason for hiding this comment

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

Another tab to remove?

Copy link
Member

Choose a reason for hiding this comment

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

There are a few of these in the PR. One in each tool it looks like. Unless I'm missunderstanding the github diff markup.

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't think you are misunderstanding.

# setup command line parser
parser = U.OptionParser(version="%prog version: $Id$",
usage=usage,
description=globals()["__doc__"])

if len(argv) == 1:
Copy link
Member

Choose a reason for hiding this comment

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

Happy with this to catch use of tool with no options

@@ -50,12 +48,22 @@ def main(argv=None):

return

elif argv[2] in ["--help", "-h", "--help-extended"]:
elif len(argv) > 2 and argv[2] in ["--help", "-h", "--help-extended"]:
Copy link
Member

Choose a reason for hiding this comment

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

I think this elif can be removed. The tools all have -h/--help/--help-extended options so no need to catch anything here

Copy link
Member Author

Choose a reason for hiding this comment

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

My guess is that this was added because the standard --help within each tool doesn't output the version number?

Copy link
Member

Choose a reason for hiding this comment

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

Ah, maybe.

On a related note, the --version options for each tool also don't properly return the version. Should probably just remove that option from the tools and make it available via umi_tools --version only

@TomSmithCGAT
Copy link
Member

TomSmithCGAT commented Jun 8, 2022

Hey @IanSudbery. Assuming you're referring to the below and the line numbers are from this PR?

elif argv[2] in ["--help", "-h", "--help-extended"]:
print("UMI-Tools: Version %s" % __version__)

I'm not sure what was going on with that elif either. It looks like I added it when we split into multiple tools to print help when a tool is specified and then you changed the output to be the version number (0101494 ). Regardless, each tool command line has help options added so no need to catch it in umi_tools.py.

I'm fine with having the same code in each tool to output help if no options are given. I agree it would be best done centrally though if you can be bothered recoding. I guess the easiest way to do it would be to catch instances where len(sys.args)==2 after the checks for version/help options, print the line you have about needing to add required options and then add --help to the sys.args and call the tool module main. I can't imagine us adding a tool with no help in the future since our base arg parser adds --help anyway

@TomSmithCGAT
Copy link
Member

Can't see how to comment on lines that haven't been updated in the PR but L46 in umi_tools.py:

elif len(argv) == 1 or argv[1] == "--version" or argv[1] == "-v":

That len(argv) == 1 can go, since that case is met by the if and causes the help to be printed.

Minor thing.

@TomSmithCGAT TomSmithCGAT reopened this Jun 8, 2022
module = importlib.import_module("umi_tools." + command, "umi_tools")
except ImportError:
print("Command %s not recognosied" % command)
print()
Copy link
Member

Choose a reason for hiding this comment

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

What's the print() for?

@IanSudbery
Copy link
Member Author

can't imagine us adding a tool with no help in the future since our base arg parser adds --help anyway

Thats not what I meant. I guess I was thinking about a tool that had no required arguements. For example, you could imagine that if extract had a default --pattern it could be run:

cat my_reads.fastq | umi_tools extract > my_reads.extracted.fastq

Although of course it doesn't, and I think all our tools require options of some sort (although come to think of it the new prepare_for_rsem or whatever we are going to call it might not).

In the above len(argv) == 1, but there is nothing wrong with it. Although perhaps this is just premature optimisation on my part.

I'll clean up the rough tabs.

@TomSmithCGAT
Copy link
Member

Ah, got it. Yeah, that is a good point. Probably being optimistic about future tools being added 😉

@IanSudbery
Copy link
Member Author

Whitespace should be tidied up.

@TomSmithCGAT
Copy link
Member

Noticed in passing that a lot of the changes to umi_tools.py are also in #506. Should we first merge that one so that the contributions include @[epruesse]?

@IanSudbery
Copy link
Member Author

IanSudbery commented Jun 8, 2022 via email

@TomSmithCGAT
Copy link
Member

@IanSudbery - This is OK to merge, right?

@IanSudbery IanSudbery merged commit a5b3489 into master Sep 26, 2022
@TomSmithCGAT TomSmithCGAT deleted the {IS}_fix_help_messages branch October 3, 2024 09:26
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