Currently the API for setting up fuse is kind of clunky and requires setup/teardown by the user. Additionally, there could be some issues where multiple users try to setup setup/teardown fuse in the same target directory.

Current

import hg
hg.fuse.start('/path/to/dir')
path = hg.fuse.path('https://example.com/data.bigwig') # /path/to/dir/mnt/https/example.com/data.bigwig..

Proposal

Setting up FUSE should happen in the command line if possible

python -m hg.fuse path/to/dir # sets environment variable

import hg
path = hg.fuse_path('https://example.com/data.bigwig') # just a utility that looks up the global fuse process and returns the correct path

At a minimum, something like:

python -m hg.view ./data/data.mcool ./data/data.bigwig # opens web browser with view

inferring tilesets, tracks, and track types. But this API falls apart quickly for more complicated views.

Perhaps more useful would just be to have a nice way to open an hg view in the browser (rather than jupyter notebook). Then users can just write python scripts that create the configurations and end with hg.open(viewconf)..

ugh #30 breaks the higlass plugin support since higlass is no longer loaded as a global....

Motivation

The background server in hg runs on a separate port. This works fine when notebooks are local because notebooks are located on localhost:XXXX and are able to make requests to another local port.

An issue arrises when using remote notebooks because the JS client needs to make requests to a separate port on the remote server. (read: HiGlass client gets a url for http://localhost:12345 in user browser but it's for the remote server port 12345)

Solution

The good news is that there are solutions to this within notebooks. In Jupyter/MyBinder we can use jupyter-server-proxy, but we want to avoid this with Google Colab and locally. The strategy is just to modify the server url based on the context of the notebook. For the following URL, here's what needs to happen:

http://localhost:12345

• Local Jupyter - no-op, should just
• Remote Jupyter/MyBinder (running on localhost:8888) http://localhost:8888/proxy/12345
• Google Colab - no-op! Colab uses a service worker to proxy authenticated requests from the client and fixes this issue for us!

Alternatives

The last solution from Colab is really elegant (using a service worker), but I couldn't inline a service worker of my own into hg/display.py to inspect the rendering context and transform URLs.

The background server is basically copied from gos. Extracting this functionality generically would be useful.

Current

import hg

t1 = hg.track(...)
t2 = hg.track(...)
t3 = hg.divide(t1, t2)

Proposed

import hg

t1 = hg.track(...)
t2 = hg.track(...)
t3 = t1 / t2

Pros - currently implemented in higlass-python. More concise
Cons - could get confusing with the view composition API

Currently API usage looks like this:

import hg
import hg.tilesets

ts = hg.tilesets.bigwig('data.bigwig') # create tileset
ts = hg.server.add(ts) # returns a TilesetResource

hg.viewconf(hg.view(track))

This makes adding resources to the server explicitly, but is a bit verbose and will be repeated for every tileset.

Alternatively, we could just export hg.<tileset>: convenience methods for adding tilesets to the server:

import hg

ts = hg.bigwig('data.bigwig') # create tileset and add to server, creates uid based on path
hg.viewconf(hg.view(ts.track()))

The current API is pretty clunky for arranging multiple views. I really don't like the View.move API. The challenge is the each view contains a layout which is describes how it is positioned in the global context. This means that users must understand and be explicit about the grid system.

Current

import hg

view1 = hg.view(...)
view2 = hg.view(...).move(x=6) # positioning of views is explicit, and requires users to understand grid

hg.viewconf(view1, view2)

I think the most desirable API is one where a view can be defined in isolation, just width and height, and then we provide utilities for stacking views. e.g.

Proposed API

import hg

view1 = hg.view(...)
view2 = hg.view(...)

hg.viewconf(view1 / view2) # change y for view2 by view1
hg.viewconf(view1 | view2) # change x for view2 by view1

Running a remote notebook that loads remote file works for me with a couple of additional actions:

1. Run jupyter with specifying --ip, it should be the same as how you access the notebook:
   jupyter notebook --no-browser --port=9998 --ip=localhost

2. Enable proxy right after import:

import hg
hg.server.enable_proxy()

It will be great to have that explained in the docs!

The HiGlass UI allows more sophisticated configuration of locks. These configurations aren't currently expressed via the hg.lock API:

Perhaps something like:

hg.lock(view1, with=view2)
hg.lock(view1, view2)

I think the challenge is that locks are context specific, so defining them as independent objects is challenging.