It is not possible to disable external plugins #17464
Comments
|
Thanks @mrclary for opening this one! This requires a new release of Spyder-terminal. |
|
I already tried out the fix that @ccordoba12 suggested but it still has no effect. What is weird for me is that I added the option to not be able to disable this plugin. So I'm not sure if we need to check the teardown mechanism for third party plugins. |
|
That's one thing, but I was talking about adding Since that option is missing, then Spyder can't read/write it to disk when enabling/disabling the plugin. I think that should solve the problem, according to what @dalthviz found. |
|
I already tried that option, and it is not working. |
|
Mmmh, that's bad news. @andfoy, any ideas about this? |
|
I think the problem is related to the way the config is being handle for external plugins (this is not only happening with spyder-teminal but also with the spyder-boilerplate plugin used in the slow test) so if you use spyder/spyder/app/mainwindow.py Lines 867 to 873 in 639465f enable: false config:
|
|
A while ago with @steff456 we did reached the same conclusion as Daniel, because of the current configuration implementation, an external plugin configuration is picked only after the plugin loads. In order to fix this, all configurations should be available at all times, regardless if a plugin has loaded. However, this requires a (potentially extensive and expensive) implementation of the configuration system that needs further discussion and implementation |
|
Ok, so the solution for now is not allowing Spyder-terminal to be disabled in |
Should we consider reverting the inclusion of spyder-terminal in the standalone applications until this is fixed? I don't know which is better: to have the plugin but unable to disable it, or not have the plugin yet... |
That could be a possibility. For that there is some missing code in the Plugins config page to also check for spyder/spyder/api/plugin_registration/_confpage.py Lines 41 to 43 in 9e545f8
I'm not sure either but at least we shouldn't show the option to disable the plugin if that can't be done
That could be an interesting approach. It could be like a list of disabled plugins maybe or a dict where each entry key is the name of the plugin and has if the plugin is enabled or not as value? |
|
When I saw this issue a while back I decided to just not allow Spyder-terminal to be disabled because at the end as it currently is a third party plugin people have to install it in order to use it. So it seems weird if someone install the plugin and disables it, because it will be the same as just uninstalling it. We could just prevent third party plugins to not be able to disable them for now while we think of a solution that is not that hard to implement. |
|
Our proposal back a time ago was to create a higher-level configuration file that mapped each section to the place where it should looked for ( |
The issue with this approach is that we will need to create an instance of the plugin to get all its configuration, letting the "disable/enable" option just aesthetic and not reducing the amount of things that Spyder has to load at startup |
I think Spyder-terminal is mature enough to be part of the installers. Since solving this problem the right way will require a good amount of work, I propose to add the necessary code to Spyder-terminal so that it creates terminals only if it's visible at startup. In other words, if the user hides it and then restart Spyder, the plugin wouldn't do anything. This is not the same as a full teardown, but it's pretty close. |
That's exactly what I was thinking. In principle, the Spyder application only needs to know two things with regard to plugins: 1) is it available (code is installed); and 2) is it enabled. The plugins themselves don't need to control these things, and the Spyder application wouldn't need to load a plugin in order to get that information.
I agree that a well-implemented solution is better than a quick one. Why do we need to segregate the internal/external plugins? I also noticed that the internal plugin configurations are included in Spyder's configuration file, but external plugins have their own configuration file in their own directory. Is there a reason why we treat these plugins differently? I understand that "internal" plugins are included in Spyder's source code, but it seems to me that regardless of whether a plugin is "internal" or "external" they should be treated exactly the same. Perhaps each plugin should have its own configuration file in its own directory, does not have an I don't know what a "higher-level configuration file" would look like, but it seems to me that only a single configuration file for Spyder is best, even for project-wise configurations. For multi-project implementation, I think the same paradigm as for plugins would work: a
I agree, except that for the macOS app, the user cannot choose to install/uninstall it. I think we've discussed before the desire to have a package manager in Spyder, in which case users would be able to install/uninstall Python packages. When we implement this, I think this idea could also be extended to Spyder's plugins.
I don't completely understand all the plugin mechanisms, so perhaps I'm mistaken, but wouldn't having Spyder maintain a list of available plugins and whether they are enabled mean that Spyder does not have to load the plugin to get that information? Only if a plugin is enabled does Spyder need to load the plugin, and only in that instance does Spyder need the plugin to serve up its configuration? |
@ccordoba12 whether or not Spyder-terminal is enabled/disabled, closing the Terminal pane is honored, i.e. upon restart the Terminal widget is not visible and remains deselected in View->Panes->Terminal. I'm sure that the plugin is still loaded, but as far as the user is concerned, it may have the same effect. So maybe this is good enough for now? or just disable the enable checkbox in Preferences? |
|
@mrclary on our last meeting we decided that for Spyder 5.3.0 release we are just going to remove the external plugins from the |
ccordoba12
changed the title
ccordoba12
changed the title
|
To add a bit of extra context to this issue: On my company laptop, the process started by spyder-terminal gets stuck and starts using 100% CPU. While this is probably an issue with my laptop, rather then with spyder-terminal, it would be nice if I could disable the plugin (or at least not start the server process). |
Description
What steps will reproduce the problem?
The spyder-terminal plugin is enabled despite disabling in Preferences->Plugins.
spyder_terminal_err.log
Versions
Dependencies
Dependencies
Environment
The text was updated successfully, but these errors were encountered: