make plot updates work outside ipython notebook

[peendebak]

This PR makes plot updates work when working outside ipython notebook.

Current approach is to duplicate the functionality. Another option would be to perform the updates without the notebook functionality. Note: using ipython is fine with me, but I would like to run my code outside the notebook.

[alexcjohnson]

Cool! Is there a similar test that positively identifies Spyder? It can certainly do some (graphical) things that you can't do from ipython running in a bare terminal, so it would be nice to configure our plots to reflect this.

What I would love to do is:

• move in_ipynb into qcodes/utils/helpers.py where in_notebook is now
• also include the 'ipy' in repr(sys.stdout) test in in_ipynb (or maybe vice versa, keep the name in_notebook as this is used various other places... but I'd also be happy if you want to replace it with in_ipynb everywhere, it's a more specific and thus better name.) The reason for this is I want the result of this call to be process-specific, and it looks like when you start a child process it inherits the parent's get_ipython() instance.
• make a related helper function for Spyder
• make sure the base __init__ does the right thing in any of these three environments - so it loads the plots in either interactive environment, but doesn't load the javascript widgets unless it's in Jupyter, and doesn't load anything Spyder-specific unless in Spyder.
• also make sure BasePlot doesn't import anything it can't use in its current environment

[alexcjohnson]

may also need AttributeError in case get_ipython() is defined but returns None? And to play devil's advocate conceivably KeyError (though it looks like unless get_ipython() radically changes its API you can supply garbage keys with no error)

[peendebak]

@alexcjohnson I added the helper function for Spyder. Checking whether we are in a notebook environment is not really possible it seems. We can check whether we are running in ipython, but not to which frontend we are connected.

The .halt() should indeed be added, but the big question is where and how. I would prefer a single update module in qcodes, with options to add callback functions. I would use the current update widget for this if it was independent of the ipython notebook.

[giulioungaretti]

@peendebak the design of ipython "forbids" to know if there is any, and which kind of frontend. (The techincal details are kind of very low level, but I can give you some if you want ❤️ ).

The IPython, actually the Jupyter, team suggests always to write code independent from the frontend when you are writing a module, else you can introduce subtle bugs (especially on different platforms).

[eendebakpt]

@alexcjohnson Is merging this PR possible? If not I will make a smaller PR that prevents the HiddenUpdateWidget from loading as this crashes my system.

[alexcjohnson]

@eendebakpt sorry for letting this languish. Unfortunately I could not make this work correctly in notebooks - including bringing back your in_ipynb which doesn't seem to work in the latest Jupyter. Maybe that's why you axed it, but without that we have no positive test for a notebook vs terminal IPython. So I don't think we can merge this unless we can find another test that does work.

@giulioungaretti it must be kosher to tell the system what front end it's running in, yes? ie I'm thinking we should move to a system where instead of trying to infer the environment, the user specifies it. So instead of:

import qcodes as qc
qc.show_subprocess_widget()

we do:

import qcodes as qc
qc.init_jupyter()
# maybe optional args for whether we want a subprocess widget,
# and whatever other stuff we create later... these options can also go in
# a config file once we make such a system.

and a similar one in spyder:

import qcodes as qc
qc.init_spyder()

and if you don't call any of the qc.init_* functions we disable all graphical/interactive features. @peendebak @giulioungaretti thoughts?

[peendebak]

Sounds reasonable. I think that if would be safe to allow a reasonable subset of the features if none of the qc_init_* is called. (I am thinking of allowing at least pure matplotlib)

If we do find a good method to detect our system, then we can always make either init_jupyter or init_spyder run automatically.

[alexcjohnson]

I am thinking of allowing at least pure matplotlib

It'll be allowed regardless, by explicitly calling from qcodes.plots.qcmatplotlib import MatPlot - we just need to make sure that we don't import this in every process that imports qcodes (loops, instrument servers and data servers), because mpl is so huge and resource-intense.

[qcodes-bot]

Here is an overview of what got changed by this pull request:

Issues
======
- Added 1

See the complete overview on Codacy

[qcodes-bot]

Issue found: The if statement can be reduced by returning bool of test

[giulioungaretti]

@MerlinSmiles @eendebakpt this is superseed by the new config options and #290 .