[IPython-dev] Proposal: soft moratorium on re-architecting for 5.0
Fernando Perez
fperez.net at gmail.com
Fri Jun 26 19:45:43 EDT 2015
On Fri, Jun 26, 2015 at 4:09 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> The moratorium I propose would be left to our judgement to implement -
> it's a principle rather than a rule. I'd make an exception for the
> conversion to Typescript, because Matthias has already spent significant
> time on that, and I know he's champing at the bit to finish it. Widgets
> would be exempt, because we've made it very clear that they're liable to
> change significantly, and they shouldn't much affect development of the
> notebook itself.
While I hear very much the spirit of what you are saying, and I certainly
think that we can't lose sight that the *only* thing that ultimately
matters is whether we serve our users well or not, there's a big piece that
is already burning under us that probably can't wait. In fact, at the last
dev meeting, Jason already posted his new draft code in this direction:
https://github.com/jasongrout/phosphor-notebook
and this is part of the reason why Matthias has been working on the
Typescript conversion, and also one of the big bottleneck points: we know
that multiple folks want to customize the notebook UI more heavily, and in
its current incarnation, that's very, very difficult. And for multiple
teams working in different directions, probably impractical/impossible at
the end of the day.
The current Notebook is, in a certain sense, where the core IPython code
was sometime in the 0.9-0.10 period: highly functional, yet highly
monolithic and very difficult to change, adapt or extend. And I really
think that, just as much as eventually we had to bite that bullet, and how
we benefitted from doing so at the time, we have to do the UI restructuring
now.
I really don't see how, right now, multiple folks are going to be able to
simultaneously work on the notebook codebase being as monolithic as it is.
So yes, I do hear you, and I think it's important that we don't lose sight
of the value for our users. We can't become a project that only looks at
its own development needs and never produces features that actually matter
to its users. That's more or less what Python did with Python 3, and we
all know how that went...
But I do think that we've accrued sufficient technical debt with the
codebase of the notebook, and we have enough pressure *already at our
doorstep* from multiple fronts regarding the need to implement many
different types of tools and ideas atop the web frontend, that we need to
open that up.
What I hope is that over the next few days at Scipy, when most of you
(sadly without me) have a chance to meet face to face, you'll be able to
hatch a plan to do this in a way that doesn't lose track of the important
goals:
- do a minimal refactoring that preserves today's functionality, even if
there's perhaps a small loss in polish on first release.
- get a more decoupled codebase that will allow us to build the various
pieces we need.
But I honestly don't see the current notebook codebase supporting the
pressure we have already on it without a refactoring right away, precisely
so that we can let more folks build new functionality...
Cheers,
f
--
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20150626/4fa751f3/attachment.html>
More information about the IPython-dev
mailing list