[IPython-dev] [IPython-user] Development plans update

[Fernando Perez]

On Jan 30, 2008 2:34 AM, Ville M. Vainio <vivainio at gmail.com> wrote:
> On Jan 30, 2008 9:57 AM, Fernando Perez <fperez.net at gmail.com> wrote:
>
> > 1. We push out an 0.8.3 release with a fair amount of care.  We
> > actually go through Trac and find anything we can reasonably expect to
> > fix and try to close it.  This would likely be the 'end of life' of
> > the series.  I'm willing to participate on this work directly, since I
> > know the codebase pretty well, but obviously it's not a decision I'll
> > push without the agreement of Ville, Jorgen, Walter and the rest of
> > the team.
>
> I feel I have to chip in on this -
>
> I don't see the need to declare "end of life", quite on the contrary.
> We should call it "complete". New Extensions can still be created
> (they are pretty independent of the core), and I don't see a problem
> creating some new extension points if need be (they can be trivially
> added, and can be easily ported to next-gen IPython as well).

Well, the problem I see is twofold:

1. Finite developer resources: in building the new system so that it
is truly as functional in a terminal as today's ipython is, we'll need
your eyes, Walter's, etc.  There's just too much code in there beyond
what I originally wrote for me not to make possibly serious mistakes.
I'm not sure if you'll have the time to both do work on the trunk and
to also help us ensure that the new code really covers all the bases
of the trunk.  There will also be design decisions, API discussions,
etc, where your input would be very important, so we don't
accidentally implement something in a way that breaks parts of the
trunk you've worked on that I don't know well.  But if you think that
you can keep things moving on both fronts well, obviously I'll be the
last to complain :)

Furthermore, eventually the point is that the new code should be much
cleaner to develop for, so that nobody should need to use today's
trunk.  We want to retain 100% feature coverage, except with a cleaner
and more modular codebase that is easier to reuse in various ways.  So
I'd hope that any work you are interested in doing (be it Leo or
anything else) would also make more sense there at some point.

In my view, the sooner we reach feature parity, the better off we'll
all be, since maintaining two parallel lines of development causes
confusion, and that will increase once the two begin to seriously
overlap in functionality.

2. Name collisions: we called the new code with that silly '1' at the
end just to avoid namespace clashes in case insensitive filesystems,
where

import ipython

would clash with today's package that is called IPython.  And
eventually, we'll have a script that will be called just
'/usr/bin/ipython', that will clash with today's.  So at some point it
will become hard (without path tricks) to run both codebases at the
same time, and we'll have to seriously deprecate the existing trunk.
Think of it like major linux kernel revisions: while it's easy to run
say 2.6.21 and 2.6.22 in parallel, it's impossible to run 2.0.10 and
2.6.22 on the same system, because too many low-level structures are
incompatible.  At some point you need to make the jump and transition
over, and we'll reach that point with this code.

> However, I'm more than happy to reject as "WONTFIX" everything that is
> disruptive to the core, or would require lots of work (bye bye,
> unicode defects) :-P

Here's one for you :)

http://ipython.scipy.org/ipython/ipython/ticket/156

> Also, we should still keep accepting patches that are obviously correct.
>
> The bottom line is, if something won't require much time, I don't see
> a problem submitting it to trunk. Most importantly, as far as Leo
> integration goes, I would like to do that with IPython trunk. on
> IPython side, this will happen mostly in Extensions/, and i don't
> foresee much (if any) changes to IPython core.
>
> One important point regarding IPython1 is dogfooding. We need to get
> it to "usable" state quickly, in order to give it some testing (I
> currently depend heavily on trunk for my daily work).

Yes, fully agreed.  That's why I'd like to make the transition to that
state be as short as possible, so we begin the dogfooding cycle
ourselves.

> Does the current ipapi work with IPython1 already?

No, not yet.

Cheers,

f