Move viewer package to larray-editor project

[alixdamman]

No description provided.

[alixdamman]

If we move content of viewer package to larray-editor, that means users will have to replace

from larray import *

by

from larray-editor import *

if they want to call edit(), view() or compare()

[gdementen]

Oops, yes indeed. In that case, we need a changelog entry and a placeholder module in larray with a Deprecation/FutureWarning telling users to add that import (in most case they will still need "from larray import *").

[alixdamman]

For the documentation, adding larray-editor as a dependency in doc/environment.yml involved that we MUST provide a linux-64 version of larray-editor =D
The best way would be to put larray-editor on conda-forge.

[gdementen]

Indeed. Let's hope they will react faster than for larrayenv...

[alixdamman]

If I add larray-editor in environment.yml, I got the correct documentation for view(), edit() and compare() but I loose the possibility to use matplotlib with the ipython directive:
ipython/ipython#6131
This issue is open since a long time and there is still no solution. I tried many workarounds but none worked.

I like to use matplotlib with the ipython directive because plots are generated automatically when running Sphinx. I wonder if we shouldn't write a separate documentation for larray-editor and use intersphinx or simple hyperlinks.

[alixdamman]

What do you think ?

[gdementen]

Grrrr. Computers are never as easy to work with as I'd like. It seems really silly to have a separate documentation for just 3 functions, but I guess that for users, as long as those functions appear in the "overview" page of the api doc (http://larray-test.readthedocs.io/en/documentation/api.html) and they can click the link, they will not care if it's another project. For us developers, I fear having a separate documentation for larray-editor will bring too much overhead. We already have extra overhead from the separate package + repository + issue tracker , which I am not very fond of... but if we have no choice let it be so. As a general comment, I wonder if a separate package within the same repository (if that is easily doable -- but I do not see any reason it wouldn't) wouldn't be more efficient for us?

[alixdamman]

One option remains: instead of installing larray-editor via conda in environment.yml, we could do this via pip (the setup.py file for larray-editor has no dependencies).
See example given in https://conda.io/docs/using/envs.html#create-environment-file-by-hand

[gdementen]

duh? I don't get why this would solve the matplotlib vs sphinx vs ipython directive issue (which I do not understand), but it would indeed solve the problem of us having to provide a linux package so that readthedocs can build our docs. That seems like a nice solution to this problem, as relying on conda-forge packages to build the doc does not seem like a good idea anyway given the time it takes them to build the packages, it would make releasing a new version even longer.

[alixdamman]

The problem with the matplotlib vs sphinx vs ipython directive comes from the automatically selected backend for matplolib. If Sphinx detects that Qt is installed, the chosen backend will be Qt. As long as Qt is not involved, the ipython directive doesn't mess up with matplotlib.

[gdementen]

"If Sphinx detects"... you mean "If matplotlib detects", right? Did you try setting matplotlib backend explicitly? It can be done either using:

import matplotlib
matplotlib.use('backend_name')

or via the MPLBACKEND environment variable.

See http://matplotlib.org/faq/usage_faq.html#what-is-a-backend

[gdementen]

Either way, it would be nice if you could finish this issue, because having the code in both places is annoying.

[alixdamman]

closed by PR #346.