IMHO one does not need supernatural resurrection powers to port a dead python2 project of sagenb size to python3---given that all of its python components are python3 compatible (which was not true for Twisted until a couple of years back).

I don't really see any reason to not keep the legacy notebook around for quite some time, granting that it will not receive much attention. We just got a support request from someone using Sage 4.6 (!) who really didn't want to upgrade; this is positively new compared to that.

But I definitely agree that whatever the absolute minimum needed to get sagenb to work minimally with python3 is fine.

Please test ​https://github.com/sagemath/sagenb/tree/1.0.rc0
(copy of the current master)
before I go ahead with making a new Sage package.
It works for me following the instructions in HACKING (updated, to take care of changed names and of the need to deal with mathjax).

What is the current status of this ticket (as opposed to the documentation build)? I thought at least some of these issues were dealt with. If it's just the graph functionality those can certainly be disabled, as I don't think they have worked properly for some time. If it's certain dependencies that is required for py3 that is somewhat different.

Thanks for the release, Dima. It will not yet be fully py3-compatible, but this should not prevent us from being able to install sagenb in py3-sage.

This second part means : first remove the conditional statement on PYTHON3 in spkg_install (on top of the changes in #25394) and do something for the lines about mathjax in this spkg-install. I managed to install sagenb in py3 sage by commenting out these mathjax lines, but this is obviously not a correct solution.

What would "full py3 compatibility" entail? Just curious. THANK YOU for this work.

Well, this just means that somebody has to install sagenb on py3-sage (using the branch here and also the hacking instructions for sagenb to work with a git branch for sagenb) and try running "sage -n=sagenb", fixing step by step all errors (in sagenb code) that occurs until the notebook finally starts. This probably implies caring about unicode (str versus bytes). But there could also be other bad surprises as well. I have started to do that, but have very urgent other matters to handle.

Also, on OS X at least, the command should be ln -s -h ... – as it is, if the mathjax link already exists, then the current command creates another link within that linked folder. It is okay if the sagenb/data directory contains

mathjax -> ../../../../../share/mathjax/

but it doesn't make sense for $SAGE_LOCAL/share/mathjax to contain this.

(On OS X, the documentation for the -h flag says "If the target_file or target_dir is a symbolic link, do not follow it." There is also a -n flag: "Same as -h, for compatibility with other ln implementations.")