[OSGeoLive] Jupyter Notebooks Development Approach

Seth G sethg at geographika.co.uk
Wed Nov 7 02:36:56 PST 2018


Hi all,

I've a few questions / thoughts on the Jupyter Notebooks and their use in OSGeoLive.
>From the IRC logs I found the following new wiki pages by darkblueb to discuss/track progress on Jupyter Notebooks. 

https://trac.osgeo.org/osgeolive/wiki/JNB_Notes
https://trac.osgeo.org/osgeolive/wiki/Jupyter

There is a new git repo at: https://git.osgeo.org/gitea/osgeolive/OSGeoLive12-Notebooks
The former git repo is at https://github.com/OSGeo/OSGeoLive-Notebooks

A few questions/comments on this:

- Is the GitHub repo now "dead"? Or will notebooks be pulled into here from the Gitea branches?
- What happens to all the notebooks in this repository, can they be found in the new Gitea branches?
- If it is dead then should it be marked as such?
- OSGeoLive development and docs seems to be now split across Trac, wiki.osgeo.org, GitHub, and Gitea. It is a lot of tools / confusion when trying to get into the development process. 
- The new repo is named OSGeoLive12-Notebooks - should this have the version name in the repo name if it is to be used for the long-term?

The other main decision to take is Python2/3 on OSGeoLive. There was some discussion on this at http://irclogs.geoapt.com/osgeolive/%23osgeolive.2018-10-01.log
The current OSGeoLive12 VM runs Jupyter under Python3 (and I believe it is only possible using Python3 now - see https://github.com/jupyter/roadmap/blob/master/accepted/migration-to-python-3-only.md#statement-of-the-problem )
I ran into some issues setting PYTHONPATH to pick up the MapScript .so file, as this then stopped Jupyter from running so have to currently hack around with sys.path in the notebook itself. 

Notebooks themselves can use either a Python2 or Python3 kernel. I'd suggest for the quickstarts each Notebook can choose whether to use Python2 or Python3, and note this on an introductory page. The main issue remaining I'm guessing is the Python dependencies for other installations, and making sure we have minimal duplication of Python libraries. 

Maybe a first step is to note all the top-level Python libraries installed on OSGeoLive, their versions, and any of the software packages that depend on them. I can make a start on this. 

Thoughts and comments welcome. 

Regards,

Seth


--
web:http://geographika.co.uk
twitter: @geographika


More information about the osgeolive mailing list