pysal / geopyter

GeoPyTeR: Geographical Python Teaching Resource
68 stars 17 forks source link

FR: Support remote notebooks #38

Closed sjsrey closed 4 years ago

sjsrey commented 5 years ago

I don't think we ever got around to implementing the use of remote notebooks, which would obviously be a rather useful feature since it saves the user even having to download/clone notebooks from GitHub! Behind the scenes we can always download to a local tmp directory in order to pass the data to our processor, but the user doesn't need to know that.

So something like: @include { 'nb' = 'https://github.com/kingsgeocomp/code-camp/blob/master/notebook-02.ipynb' }

The only downside I can see to this is that if you want a particular version you can't use a branch without changing the URL... but I think you can still use tags that are on the master right? So we could still (I believe) write:

@include { 'nb' = 'https://github.com/kingsgeocomp/code-camp/blob/master/notebook-02.ipynb', 'tag' = 'v1_2', # Note, doesn't exist, just for illustrative purposes 'select' = 'h1.Understanding Lists' }

jreades commented 5 years ago

It looks to me like read_nb is the key thing here in terms of enabling remote files to be used — this makes a call to:

# Read-only in UTF-8, note NO_CONVERT.
with io.open(nb, 'r', encoding='utf8') as f:
 nb = nbformat.read(f, nbformat.NO_CONVERT)

If that can work with remote files then this is a trivial fix. If it can’t then we’d probably just want to download and save a copy to a local temp directory.

The other thing I can see is that the ‘src’ attribute needs some thought as I’m not sure that we had envisioned a remote URL then calling other notebooks to be included. This should be solvable if the general problem is solvable (you just need to remember to check if src is local or remote and then parse the includes accordingly) but as with all things that seem easy a lot will depend on whether I came up with an elegant solution to this back in the day.

sjsrey commented 5 years ago

I think we can handle this as we can test for the scheme in the opener and dispatch accordingly. On a related note, urllib has undergone major refactoring between python2 and python3. We started with python2 for this project but I think we might want to revisit that decision as a lot content is now python3 only. We probably don't want to have two versions of gp, or one version that can support 2 and 3 (having scars that are still not healed from the pysal 2 to 3 transition).

jreades commented 5 years ago

Yep, fine with dropping support for python 2!

-- m: 07976987392 e: jon@reades.com s: jreades On 27 Sep 2018, 17:38 +0100, Sergio Rey notifications@github.com, wrote:

I think we can handle this as we can test for the scheme in the opener and dispatch accordingly. On a related note, urllib has undergone major refactoring between python2 and python3. We started with python2 for this project but I think we might want to revisit that decision as a lot content is now python3 only. We probably don't want to have two versions of gp, or one version that can support 2 and 3 (having scars that are still not healed from the pysal 2 to 3 transition). — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

sjsrey commented 5 years ago

Cool. I'll work on refactoring to 3 only and handling the remote v. local reads.

jreades commented 4 years ago

Resolved. Though I think it still outputs a message the remote reads aren't supported.