And we are not removing it for all the legacy reasons that you listed. This > thread is about what format new notebooks are supposed to be. Anybody who > prefers SageNB can still use SageNB > > But how easy will that be? It already sounds like sagenb notebooks are not really portable to Jupyter.
> But the fact is: Its unmaintained/-able, and the longer we wait the more > painful it'll be to switch. How is waiting another year going to help? > Because by then there will be another book explaining how to use SageNB? Do > you think the book author is going to be happy that we never made it clear > that SageNB is on the way out? SageNB is an evolutionary dead end, and the > only question is how deep into that hole do we want to go. > As William said, the answer is to either find a way to make them port, or to find a way to gracefully detect that someone has existing sagenb worksheets (perhaps slightly more gracefully than just checking DOT_SAGENB since that doesn't mean they actually did anything) and either ask to upgrade to Jupyter worksheets, if that's possible, or make it very easy to change a default setting. Could there be an environment variable DEFAULT_SAGE_NOTEBOOK that one could have incredibly explicit instructions for how to use? (Would making an alias work in this context? Not in the sage: notebook() situation, I guess.) But it has to be idiot-proof. Imagine the following conversation at the Sage table: Customer (yes they are customers!): Will I ever have any problems with upgrading? Sage rep: Yep, we will make it so all your old stuff is never upgradeable with essentially no warning other than some cryptic command line thing you don't even see because you only look at your browser! Customer: I didn't hear you right, I think? You mean, "we'll support legacy stuff so long it will make Microsoft look good." I mean, I don't want to still be using .doc in 2020. Sage rep: Nope, we're sort of the opposite; we won't have any 'compatibility mode' nor any incentive to upgrade your old documents; you either go to the new one - oh, by the way, it doesn't do everything the old one does yet - or you just stick with the old kind forever. Yup, I see that as a real winner. And of course this conversation can happen again whenever the next new hit comes out in five years, which it no doubt will. Writing up a very accessible (perhaps even linked to in the warning) translation guide to getting started in Jupyter would be good too. As much as there might be a bigger ecosystem for them, that is not a very compelling argument to me; otherwise we should all be using RStudio and shiny, and well basically just using R for everything. How many of those zillions of easy-to-search sample worksheets are about something like calculating elliptic curve invariants or a nice demo for a graph theory course? Probably just a tiny proportion of the ones about data science or scientific computing. On a separate note, I'm wondering how changing the default will impact those running servers. Which is a higher knowledge crowd but also one who might not be reading sage-devel (in fact likely isn't). Basically, I'm asking about any worst-case scenarios when someone upgrades from (say) 6.7 to 7.2 at the end of a school year and either doesn't read the 'release notes', doesn't even know there are release notes, or our release notes are so minimal as to be useless, or something. (I assume that commercial software has that problem of non-reading too.) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
