-
Notifications
You must be signed in to change notification settings - Fork 285
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
Fix name loader problem #4933
Fix name loader problem #4933
Conversation
01f6b97
to
3533ce1
Compare
I think this is okay to review now. A couple of notes though ... (2.) I considered adding a test-file replicating the #3288 issue, and an integration test for the fix. |
@volcan01010 would you be available to review ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me, I had one small comment though.
It is a bit of a shame there is no extra testing for the name loader so it would be nice to get hold of some test data. Is there a way we could generate some?
Yes, I can have a look at this this week. It will be quite superficial, though, as I haven't worked with these data for a while. |
As I explained above, we could ask @volcan01010 if he is prepared to release his sample file ?? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one comment from me on handling objects that aren't cell methods that show up in the list of cell methods. To be clear, I don't think this is something that needs to be fixed, but we could consider an alternative approach to erroring fast in the middle of a dataset load.
3533ce1
to
3922d79
Compare
Well, on a closer look I think we actually did have a suitable testfile all along, which was previously unused. Meanwhile, apologies for my moving this + some other tests into slightly a more logical hierarchy, it just seemed time to get that done. UPDATE: doubtful - read on!! |
OK, I confused myself there. I will fix this, this goes in draft, while I fix it |
3922d79
to
6c043c7
Compare
This should pass, once SciTools/iris-test-data#82 is merged |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One minor comment about the naming here, but more importantly:
- Having mentioned both NAME II and NAME III formats, they are both widely used in practice (due to a habit of copying NAME config without necessarily reviewing options like the output format), so I would suggest testing both. I can find/create some example output if needed.
- Can this PR please also be added as patch releases to both 3.2 and 3.3? The refactoring of the cube string representation code in 3.2 combines with this bug to mean we often cannot print a cube. While I believe we could do almost everything else with it (except save as originally raised in the linked issue), the lack of printing does not give anyone the confidence to try, so we are essentially stuck using older versions of iris for NAME.
Offline discussion of the specifics: a |
I've had a look through the PR and it looks good to me. I haven't worked on that Iris project for a while, so unfortunately I'm not up to speed to do a more detailed review. Please feel free to incorporate the test data file into the project. |
Many thanks @bsherratt
From internal discussion (peloton meeting), it seems this really is needed, so yes, we will commit to a 3.3.1 release.
Ok I will rename the new file + fix it here and in SciTools/iris-test-data#82
This sounds a useful improvement, but we should handle it as a separate issue ? |
Yay, GTG ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @pp-mo! Some tiny testing changes for you, also:
Don't forget to re-target to v3.3.x
Ok I have done that now + I think it looks pretty neat. f6853de However, It may be appropriate for @lbdreyer to also check out + OK my use of the fixture here ... So... I have defined a fixture as a class-instance-method, and labelled it "autouse=True", and it assigns data to "self" properties. It certainly seems to work, and I think it makes sense : on debugging, I find that the 'self' instance of the "Test__cell_methods" class which the fixture receives is unique for each test method invocation. So I assume that this 'self' therefore "is the test instance", and can be used to hold per-instance data as in the older style. |
Meanwhile ...
Good spot. |
f6853de
to
544bd1d
Compare
e765f71
to
efa3482
Compare
efa3482
to
9064372
Compare
Thanks @trexfeathers But I've had to squash commits to sort out the changes 😞 There was also some suggestion we might want to add the netcdf version pin from #4968 onto 3.3.x, as otherwise we will probably get occasional docs build failures. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So GitHub is telling me you've changed pretty much everything since my review on Friday, but I can only see the changes I was expecting so I'm assuming that's just the force-pushing messing things up.
So the docs build is failing again (see https://readthedocs.org/projects/scitools-iris/builds/ for the latests builds) I restarted the job a couple of times but it's getting the same HDF error. Interestingly when @pp-mo re ran the build it worked the second time |
|
Belated thanks @trexfeathers |
@pp-mo next time I'm reviewing feel free to merge in the updates instead of rebasing. It's better for my reviewing workflow and would be easier on you for resolving conflicts. (And obvs since this is a PR: squashing saves us from any long term nastiness with history) |
* v3.3.x: Update whatsnew for 3.3.1 release (SciTools#5002) Port dependency fixes to `v3.3.x`. (SciTools#4992) Fix name loader problem (SciTools#4933) Reinstate CubeList._repr_html_() (SciTools#4976) # Conflicts: # .github/workflows/ci-tests.yml # requirements/ci/nox.lock/py310-linux-64.lock # requirements/ci/nox.lock/py38-linux-64.lock # requirements/ci/nox.lock/py39-linux-64.lock # requirements/ci/py310.yml # requirements/ci/py38.yml # requirements/ci/py39.yml # setup.cfg
Addresses #3288
Draft pending :[x] tests for enhanced API[x] whatsnew