PR: Migrate RunConfig to Plugin with new API

[goanpeca]

Description of Changes

• Wrote at least one-line docstrings (for any new functions)
• Added unit test(s) covering the changes (if testable)

• Included a screenshot or animation (if affecting the UI, see Licecap)

Issue(s) Resolved

Fixes #13099

Affirmation

By submitting this Pull Request or typing my (user)name below,
I affirm the Developer Certificate of Origin
with respect to all commits and content included in this PR,
and understand I am releasing the same under Spyder's MIT (Expat) license.

I certify the above statement is true and correct: @goanpeca

[pep8speaks]

Hello @goanpeca! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2020-07-29 14:58:41 UTC

[goanpeca]

Hi @dalthviz, this one is ready for QA testing. Thanks!

[dalthviz]

After an initial test, seems like the options are working as expected 👍

[goanpeca]

This is ready for review @ccordoba12

[goanpeca]

@dalthviz and @ccordoba12 this one is ready for review.

[ccordoba12]

@goanpeca, one quick question so I understand things better: why do you think it's important to create a plugin for this config page? Since the plugin API for Run is not used anywhere in this case, it seems unnecessary to me.

Also, it seems you forgot to declare a setuptools entry point for it.

[goanpeca]

one quick question so I understand things better: why do you think it's important to create a plugin for this config page? Since the plugin API for Run is not used anywhere in this case, it seems unnecessary to me.

Again the idea of generalizing all these things is to be able to have a single way to handle all the things. All plugins are loaded in the same way no matter what (no if this is a global page do this, or if this is a completion or if this is a third party or if .... etcc you get the idea). This also applies to config pages.

This "run" plugin is a plugin that depends on the Editor AND the Console so that it can do things, so I think having it as a separate plugin (besides simplifying code in preferences/ and in main window) opens the door to handle in a cleaner way how the console interacts with the editor to run stuff. (like the current implicit dependency the ipyconsole shellwidget has on the editor). This is the plugin that should be in charge of all the Run actions (not the editor). Also the core plugin would override the run action (that would be handled by this plugin). All these things will become apparent with the editor migration (which currently hardcodes a lot of behavior and also results in circular dependencies).

That is why all the "global preferences" should become a plugin, to have a single way of handling all plugins and remove code that is doing checks for special cases. After this is made there is no need to handle "global" configs in any different way, they will basically disappear with the whole spyder.preferences module. and the configdialog.py could be moved to the configs folder or the global API directly at spyder.api.preferences.

[ccordoba12]

Ok, thanks for the clarification.