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

Check a valid service name has been provided #171

Merged

Conversation

benjaminhwilliams
Copy link
Contributor

@benjaminhwilliams benjaminhwilliams commented Nov 3, 2023

At present, a user can grow accustomed to lazily providing lower-case service names when invoking workflows.service from the command line. This works fine until you encounter the following situation:

  • Known services include DLSISPyB and DLSISPyBPIA;
  • user specifies -s dlsispyb, expecting this to be interpreted as DLSISPyB, or else expecting an error;
  • not finding a perfect match, the current logic checks whether any known service names, rendered in lower case, start with dlsispyb, finds two such matches;
  • rather than selecting either of these two matches, the program quietly continues to open a frontend and doesn't start any service;
  • user sees so warning or error, program twiddles its thumbs until manually terminated.

New logic:

  1. Check for perfect match;
  2. Failing that, check for case-insensitive match;
  3. Failing that, check for case-sensitive partial matches. If ambiguous, exit with error.
  4. Failing that, repeat 3 but now case-insensitive.
  5. If still no matches, exit with error.

- Remove some redundant parameters.
- Construct the known_services help string separately (we'll use it
again).
- Exit early if no service has been specified, instead of opening a
frontend with no service and quietly twiddling our thumbs.

No attempt is made here to migrate to argparse.ArgumentParser instead of
the deprecated optparse.OptionParser, though the 'required' argument of
'ArgumentParser.add_argument' would obviate the need for separately
checking whether the '--service' option has been invoked.
At present, a user can grow accustomed to lazily providing lower-case
service names when invoking 'workflows.service' from the command line.
This works fine until you encounter the following situation:
- Known services include "DLSISPyB" and "DLSISPyBPIA";
- user specifies '-s dlsispyb', expecting this to be interpreted as
'DLSISPyB', or else expecting an error;
- not finding a perfect match, the current logic checks whether any
known service names, rendered in lower case, start with 'dlsispyb',
finds two such matches;
- rather than selecting either of these two matches, the program quietly
 continues to open a frontend and doesn't start any service;
- user sees so warning or error, program twiddles its thumbs until
terminated.

New logic:
1. Check for perfect match;
2. Failing that, check for case-insensitive match;
3. Failing that, check for case-sensitive partial matches.  If
ambiguous, exit with error.
4. Failing that, repeat 3 but now case-insensitive.
5. If still no matches, exit with error.
@ndevenish
Copy link
Contributor

Was there anything else that needed to happen here for this to be worth merging?

@ndevenish ndevenish marked this pull request as ready for review October 30, 2024 11:04
@ndevenish
Copy link
Contributor

This looks a definite improvement, and seems to work as-is.

@ndevenish ndevenish merged commit 60cf6c3 into DiamondLightSource:main Oct 30, 2024
16 checks passed
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