Skip to content

Conversation

GuiMacielPereira
Copy link
Contributor

Description of work

As described in #35661 the Load() algorithm might load an incorrect file extension even when the extension is specified in the file name.

Summary of work

I have maintained the same behaviour for backwards compatibility, the only change I made is that if the file with the specified extension is not found, a warning is issued to let the user know that other extensions will be considered.

Further detail of work

To test:

Run the code in the original issue and check that a warning is displayed in the console log. Load the same file without an extension specified and check that no warning is displayed.

Turn on the debug level on the console log and run the code in the original issue again. Check that at first only the extension specified in the filename is considered and then all extensions are considered.


Reviewer

Please comment on the points listed below (full description).
Your comments will be used as part of the gatekeeper process, so please comment clearly on what you have checked during your review. If changes are made to the PR during the review process then your final comment will be the most important for gatekeepers. In this comment you should make it clear why any earlier review is still valid, or confirm that all requested changes have been addressed.

Code Review

  • Is the code of an acceptable quality?
  • Does the code conform to the coding standards?
  • Are the unit tests small and test the class in isolation?
  • If there is GUI work does it follow the GUI standards?
  • If there are changes in the release notes then do they describe the changes appropriately?
  • Do the release notes conform to the release notes guide?

Functional Tests

  • Do changes function as described? Add comments below that describe the tests performed?
  • Do the changes handle unexpected situations, e.g. bad input?
  • Has the relevant (user and developer) documentation been added/updated?

Does everything look good? Mark the review as Approve. A member of @mantidproject/gatekeepers will take care of it.

Gatekeeper

If you need to request changes to a PR then please add a comment and set the review status to "Request changes". This will stop the PR from showing up in the list for other gatekeepers.

When the filename contains an extension, the FileFinder will
now fail to find the file.

There are four options:

- filename contains extension + useOnlyExts=True: searches exts + extension (filename)
- filename contains extension + useOnlyExts=False: searches only extension (filename)
- filename does not contain extension + useOnlyExts=True: searches only exts
- filename does not contain extension + useOnlyExts=False: searches exts + extensions (facility)
In the case where search is run with a specified extension in
the filename, search for that extension only first.
If not found, issue a warning and try again with the
other facility extensions + extensions that were passed as
an argument.
uniqueExtensions.pop_back() avoids running search for
specified extension again.
@GuiMacielPereira GuiMacielPereira added Bug Issues and pull requests that are regressions or would be considered a bug by users (e.g. crashing) ISIS: Core Issue and pull requests at ISIS that relate to Core features and functions labels Aug 22, 2024
@GuiMacielPereira GuiMacielPereira added this to the Release 6.11 milestone Aug 22, 2024
Corrected if statement after warning from cppcheck
Unit test had failed because I had overlooked the fact that
when useExtsOnly=True, the search should fail if the specified
extensions are incorrect
@jhaigh0 jhaigh0 self-assigned this Aug 23, 2024
This behaviour was not specified in the existing unit tests,
but from what I gathered when useExtsOnly=True then only those
extensions should be considered, even if an extension is explicitly
written in the filename.
Added a few unit tests to cover behaviour that was previously ambiguous.
If useExtsOnly=True, then only those extensions should be considered.
If useExtsOnly=False, it should find the file whether the extension is
correctly specified in the filename or not.
Running the FileFinderTest.h locally doesn't use the
mantid properties meant for testing automatically, so
the search paths meant for testing are not searched on,
which causes some tests to fail.

These two lines ensure that the mantid properties for
tests are used.
Copy link
Contributor

@jhaigh0 jhaigh0 left a comment

Choose a reason for hiding this comment

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

Code is working as expected, good job. I've left some comments about cleaning up findRun while we're here making changes.

Comment on lines +107 to +108
const std::string propfile = ConfigService::Instance().getDirectoryOfExecutable() + "Mantid.properties";
ConfigService::Instance().updateConfig(propfile);
Copy link
Contributor

Choose a reason for hiding this comment

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

Wondering if this will affect other tests?
What properties do you need the config service to have which are stored in Mantid.properties, or is it not set up?
Could you just set the ones you need using the api?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought this could affect other tests, but they all ran fine.
We just need the user directories, everything else is ignored.
I'll just set the user directories using the api, I agree that is safer and clearer

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh I see, for loading the data. I know there are test data folders which hold data for unit tests specifically, maybe you can find out how those are typically used

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well, what is happening is that there is a Mantid.properties file in the bin folder but there is also another properties file in the conda environment folder, which takes priority over the one in the bin folder. When running on Jenkins, the one in the bin folder is used and all is well. When running on my machine, the one in my conda environment is used which causes the missing data directories.

I could set the data directories at the beginning of FileFinderTest by hard coding them relative to the bin directory. But if the structure of the build folder changes, then the test would start failing. I also thought about reading the Mantid.properties file in the bin folder to look for the data directories, but since ConfigService is a singleton, I can't really read the properties file without also updating the properties that the singleton holds, which is what I am already doing anyway with the updateConfig call above (unless, of course, I change the ConfigService class a bit to allow for this).

I couldn't find any other test where the data directories are updated in the config service at the beginning of the test, the closest I got was how the config service is updated several times with updateConfig in the ConfigServiceTest, in the same way that I am doing here.

I think this is the best solution we can do, because it doesn't affect other tests and even when the test is run locally, it doesn't change the properties files after running it (because at the start of workbench the priority defaults to the properties file in the conda environment).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Or I can just hard code the paths as well, whichever you prefer

Unpacked pair with auto [] and removed unecessary if statements that
checked whether strings are empty.
Adding empty string or not adding it is the same operation.
Renamed extensions -> facilityExtensions and
uniqueExts -> extensionsToSearch
Renamed exts -> extensionsProvided and
useExtsOnly -> useOnlyExtensionsProvided
Replaced previous standalone if statements with easier to understand
nested if statements.
@SilkeSchomann SilkeSchomann self-assigned this Sep 6, 2024
@SilkeSchomann SilkeSchomann merged commit dbe9e38 into main Sep 6, 2024
10 checks passed
@SilkeSchomann SilkeSchomann deleted the load-alg-correct-extension branch September 6, 2024 07:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Issues and pull requests that are regressions or would be considered a bug by users (e.g. crashing) ISIS: Core Issue and pull requests at ISIS that relate to Core features and functions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Load algorithm loading nexus if can't find the specified file extension for a given run
3 participants