Add repr()

[mccalluc]

I need to get a working environment before going much further (#64, #65), but wanted to sound out this approach. The higher level goal is to just output calls to the Wrapper constructors for the values of the notebook cells, preferably the outermost Wrapper, and it will recurse to generate the string.

repr is in general not how you should do data serialization... but that's not we're doing: We want to explain what an object is (which is a good use for repr)... and incidentally, it should be executable.

In the one example I looked at in portal-ui, it didn't seem that the Wrapper instance was modified after creation... but I'm not confident that that's generally true.

Filing this as draft. If this doesn't seem horrible, I'd like to

• get my environment working,
• turn on doctests in this repo,
• and add code like this to the other Wrapper classes.

[keller-mark]

Tested with this notebook:

[keller-mark]

Just merged #67 into master, would you be able to try the following steps to set up a fresh environment:

conda deactivate
conda env remove -n vitessce-jupyter-examples

cd docs/notebooks
conda env create -f environment.yml
conda list

Check that the version of JupyterLab is greater than 3.0.0

pip install -e ../..
cd ../../js
npm install
npm run build
cd ../docs/notebooks
jupyter labextension install ../../js
jupyter lab

[mccalluc]

(I'd like #70 to be merged before I merge this one: That brings in doc test machinery, so the test here would actually be run. Keeping as draft until then.)

[mccalluc]

@ilan-gold -- Could this much be merged? I have not personally confirmed that it actually works for each of the types, and it wouldn't be unreasonable to ask for that before going farther.

[ilan-gold]

@mccalluc Do you mean in the portal? I think it would probably be good to try this out in one of the notebooks for some of them. That should be pretty straightforward and should translate to the portal. This seems fairly low-risk so even if it doesn't work as intended, the package probably won't "break"

[mccalluc]

Close in favor of #115.