id summary reporter owner description type status priority milestone component resolution keywords cc workpackage 1142 Plugin framework is broken butler pkienzle "several people have mentioned problems with plugins recently. Thorough testing, particularly by @tcbennun and @gonzalezm, has revealed that the problem seems to lie in the loading of the plugin and the math package (quoting from @gonzalezm): 1. I create a simple model without math functions (A+B*x): OK 2. Using a math function as in the tiptool (A+B*cos(2*pi*x)): The editor gives a success message and the python file is correctly generated and saved in plugin_models. But when trying to load it in !SasView, an error appears: {{{ 2018-07-20 12:11:54 : Traceback (most recent call last): File ""sas\sascalc\data_util\calcthread.pyc"", line 274, in _run TypeError: unsupported operand type(s) for *: 'NoneType' and 'float' }}} 3. I edited the generated file to check it and everything looks correct. Then it is enough to modify it (e.g. add a space) or save it with a different name, and then the model can be loaded and it will work. 4. As the model is correct, closing and relaunching !SasView will also make the model available and it works. This could be a roundabout, i.e. first create the model, then close !SasView and then restart. But it is clearly not satisfactory. Investigating further it seems the root cause may be the loading for testing of new plugins (quoting now from @tcbennun): It seems that when you create a new plugin model, the new Python file is loaded as a module from source twice when it is checked, in pyconsole.py, check_model(). The first time, it is loaded with sasview_model.py, load_custom_model() (just to check it can be run), and the second time, with generate.py, load_kernel_module() (this happens during the unit tests). If load_custom_model() had been used twice there would be no problem, because that function caches previously-loaded modules and prevents them from being reloaded. But load_kernel_module() is separate, so the module is loaded again. The GUI generally only uses load_custom_model(), as far as I can tell, so this bug might not appear elsewhere at all. Theoretically this problem shouldn’t exist (Python docs claim that reloading a module from source re-initializes the module safely), but we’re seeing that the module’s namespace is not populated correctly for whatever reason the second time round, so it’s missing those maths functions which are imported at the top of the file. Further testing by myself shows that actually any plugin, if tested (either by the new editor module because it is just created or by running run -> Check model in the advanced model editor) once, may pass the test (it will not the second time) but will now throw errors when used. This includes downloading a model from the marketplace. Just running it as is works, as soon as it is loaded into the editor and checked (regardless of whether changes have been made) it no longer works. Exiting !SasView and restarting clears the problem. This issue is probably identical to the one that prevented #885 from being implemented (in fact we rolled back polydispersity completely). Once this gets fixed we should retest " defect closed blocker SasView 4.2.1 SasView fixed SasView Bug Fixing