-
Notifications
You must be signed in to change notification settings - Fork 18
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
Remove warnings in unit tests #509
Remove warnings in unit tests #509
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #509 +/- ##
==========================================
- Coverage 79.97% 79.92% -0.06%
==========================================
Files 27 27
Lines 3830 3815 -15
==========================================
- Hits 3063 3049 -14
+ Misses 767 766 -1
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
131b49f
to
6ed3e6f
Compare
6ed3e6f
to
106c913
Compare
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.
@yakutovicha @unkcpz I still need to test that I didn't break anything, but otherwise this is ready for review.
|
||
[tool.pytest.ini_options] | ||
filterwarnings = [ | ||
'error', |
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.
Some of the warnings that I cleaned up in this PR uncovered actual bugs so imo it's good to just turn all warnings into errors so that we keep it clean. If it turned out to be too much chore we can always revert this decision.
It is a bit unfortunate that we need so many 'ignore's here but hopefully we'll reduce this as we update our third-party dependencies.
@@ -218,26 +211,22 @@ def test_running_calcjob_output_widget(generate_calc_job_node): | |||
} | |||
) | |||
|
|||
# Test the widget can be instantiated with a process | |||
RunningCalcJobOutputWidget(calculation=process) | |||
widget = RunningCalcJobOutputWidget() |
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.
The RunninngCalcJobOutputWidget
initializer does not have calculation
as its input. This code was likely copy-pasted. This API is a bit unconsistent, since many other widgets allow passing the traitlet via constructor. But that's for another PR.
@@ -34,32 +34,22 @@ def registration_decorator(widget): | |||
return registration_decorator | |||
|
|||
|
|||
def viewer(obj, downloadable=True, **kwargs): |
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.
We can't be passing this attribute to the viewers in general because most of them do not have it, and then pass it up to the ipywidget parent which results in warnings. Since this parameter is only used in DictViewer
and FolderDataViewer
I think it is okay to get rid of it, but please correct me if I am wrong.
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.
The problem maybe the viewer return from calling viewer
directly will not be exactly the same as DictViewer
. Where the downloadable
can not pass to the viewer anymore.
I think it is fine to get rid of it but for the DictViewer
the downloadable
need to get from kwargs
.
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.
Sorry, I am not sure I got your comment. Do you want me to change anything?
The problem maybe the viewer return from calling viewer directly will not be exactly the same as DictViewer. Where the downloadable can not pass to the viewer anymore.
Yes. But other viewers may have other input parameters and we don't support them either, so I don't see why Downloadable
should be privileged in any way.
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.
Sorry, I am not sure I got your comment. Do you want me to change anything?
Never mind, I misunderstood the usage of the viewer in the first place. I was asking for changing __init__
of DictViewer
, instead of passing downloadable
but passing downloadable
through kwargs
.
It is not necessary, and your change is all good. The expected way of using the viewer
function in the AiiDAlab is by AiidaNodeViewecWidget
, which only passes the orm.Node
without any parameters.
except KeyError as exc: | ||
if obj.node_type in str(exc): | ||
warnings.warn( | ||
f"Did not find an appropriate viewer for the {type(obj)} object. Returning the object " |
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.
I don't find this warning particularly helpful since it is kinda self-evident. Also for Base types like Int
it's perfectly okay not to have a dedicated viewer.
@unkcpz can you take a look? Would be nice to get this to 2.1 version so we have more confidence in our test suite. |
Haha 🥲 That when I tried (ultimately unsuccessfully) to get rid of some warnings coming from Selenium. |
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 @danielhollas! some minor things to discuss.
aiidalab_widgets_base/structures.py
Outdated
@@ -658,8 +660,8 @@ def search(self, _=None): | |||
matches = {n[0] for n in qbuild.iterall()} | |||
matches = sorted(matches, reverse=True, key=lambda n: n.ctime) | |||
|
|||
options = OrderedDict() | |||
options[f"Select a Structure ({len(matches)} found)"] = False | |||
options = [] |
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.
Since ipywidget
use tuple as default for opitions
(see https://github.com/jupyter-widgets/ipywidgets/blob/52663ac472c38ba12575dfb4979fa2d250e79bc3/python/ipywidgets/ipywidgets/widgets/widget_selection.py#L156-L166)
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.
See the comment I just added, I think it is better to initiate the options
as a tuple.
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.
Here the options are generated dynamically from the search result and I do not see an easy way of using a tuple. Keeping a list here is fine imo.
@@ -34,32 +34,22 @@ def registration_decorator(widget): | |||
return registration_decorator | |||
|
|||
|
|||
def viewer(obj, downloadable=True, **kwargs): |
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.
The problem maybe the viewer return from calling viewer
directly will not be exactly the same as DictViewer
. Where the downloadable
can not pass to the viewer anymore.
I think it is fine to get rid of it but for the DictViewer
the downloadable
need to get from kwargs
.
@unkcpz the code is good to go from my side. However, I have not yet manually tested that I did not break anything (although we have better and better tests). If you could help with that that would be appreciated. The main thing is to test the |
I gave it a test on the QE app and it didn't break anything yet. |
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! Looks all good to me. If you have no objection, I'll merge this and give a more detail test in the app.
Cool, let's go for it, I will also test it in my app. The other PRs should merge the master now to ensure that no new warnings are introduced. CC @yakutovicha |
Fixes #490.
TODO: Test things
I extracted some fixes that were actual bugs into separate PRs, #512 and #513.
This is blocked until they are mergedNow unblocked