[IPython-dev] IPython development: course adjustment required

[Fernando Perez]

Hey Barry,

On Sun, Jun 1, 2008 at 2:26 PM, Barry Wark <barrywark at gmail.com> wrote:
> Sorry to jump in late on the discussion. As the token frontend guy, I
> think this sounds like a good idea too. My understanding is that
> following the reintegration, ipython0 will instantly be the
> terminal-based front-end for the ipython1 features. That's great. We
> can continue efforts to make Twisted-based GUI frontends for ipython1.
> But, how are we planning to make ipython0 features (such as macros
> etc.) available via the engineservice interfaces? My (weak)
> understanding of the ipython0 codebase is that much of the ipython0
> Interpreter is tied to the terminal/readline interface. Integrating
> that with Twisted is (as we've just seen) difficult. So, is there a
> plan yet for using ipython0's features in non-terminal-based use
> cases?

Glad  you pitched in.  Yes, the plan will  be simply to gradually
morph the current ip0 code so it supports the abstractions needed for
things like what you're working on.  The code is fairly tied to the
terminal, but that doesn't mean we can't untie it :)  In fact, various
people have hacked it into submission (Laurent for WX, there's a GTK
example, I've seen an OpenGL console somewhere...).

So what we'll do is simply try to do a series of targeted small
releases where we can make these changes in a somewhat controlled
manner, but admitting (and advertising) that there WILL be some
inevitable API breakages.

I took the attitude of keeping the IP0 100% frozen in time and
expecting ip1 to eventually become ipython 1.0 with a potentially new
API.  From a development process perspective, we've seen that turned
out to have problems [1].  So now we'll just move on top of what we
have, add all the (good) code that had been written for ip1 and morph
interfaces as needed.  We'll  make an honest effort to keep the most
user-facing APIs  unchanged, but I won't make any promises.  If we
have to break an API, we'll do it.  Some WILL break, period.  We'll
just need to be diligent with our api_changes.txt document so it's
always an honest reference of what has changed and when.

Cheers,

f

[1] I should say that I don't think it was all a mistake: thinking on
a clean slate for ip1 let Brian, Min and I have lots of wild-eyed
discussions (and boy did we) on a number of topics, that would
probably have been much more constrained if we felt we were working
within the confines of the must-be-respected-at-all-costs iptyhon0
codebase (and supported by the very rigid workflow of SVN).  But
still, it is now clear that we made process mistakes.  Live and
learn...  Thanks again for the well thought out feedback from
everyone!