[IPython-dev] IPython.Extensions on sys.path

[Fernando Perez]

On 11/2/06, Ville M. Vainio <vivainio at gmail.com> wrote:
> On 11/2/06, Walter Dörwald <walter at livinglogic.de> wrote:

> Yes. Though I'm not so sure about "from IPython.Extensions", it's up
> to the author of the code to determine which feels more comfortable.
> Technically, "Extensions" should all be IPython dependent (IPython
> extension plugins) but ATM it also contains stuff that is importable
> as top level modules when running inside IPython.
>
> > I'm not sure. At least there would no longer be identical copies of the
> > same module. But installing IPython would then "overwrite" the original
> > version of the module, i.e. when importing it you'll get the IPython
> > version instead of the original one.
>
> Yeah, I don't like that either.
>
> > I'd like to use Philip Eby's simplegeneric module
> > (http://cheeseshop.python.org/pypi/simplegeneric) for ipipe. xrepr(),
> > xiter() and xattrs() could benefit from being generic functions. I
> > already experimented in this direction some time ago, but now that a
> > simple standalone generic function module is available it no longer
> > makes sense to reinvent the wheel.
> >
> > Philip's OK with us bundling the module, as long as it doesn't conflict
> > with any installed version of simplegeneric, which it would (but only
> > when running inside IPython).
>
> Ok. Put it into IPython folder (not IPython/Extensions) and import it
> explicitly from there ("from IPython import simplegeneric").

I'd suggest making a subdir in IPython for third-party modules, so
that we can import them from there.  It doesn't particularly hurt us
to have to type an extra word in the import statements, and it is more
self-documenting that these are simply pulled in for convenience.
Something like IPython/contrib or 'external' can work.

from IPython.external import simplegeneric

lets us clearly know in the future that this comes from the outside.
We can simply document to users which external modules we ship as a
convenience, so they can use them from within ipython.

> I'm still -1 on removing Extensions from sys.path, though.

This one isn't terrible IMO because we're putting it, along with
~/.ipython, at the very end of sys.path, so the danger of it shadowing
a user's expected directory is minimal.  It will shadow an
ImportError, but it won't cover another directory.

What does bother me is that Python (I didn't know this) prepends any
script's execution directory to sys.path.  Try this:

longs[~/test]> pwd
/home/fperez/test

longs[~/test]> cat spath.py
import pprint,sys
pprint.pprint(sys.path)

longs[~/test]> python spath.py
['/home/fperez/test',
 '/home/fperez/test',
 '/home/fperez/tmp/local/lib/python2.4/site-packages',
 '/home/fperez/usr/lib/python',
 '/home/fperez/usr/lib/python2.4/site-packages',
 '/home/fperez/usr/local/lib/python',
 '/home/fperez/usr/local/lib/python2.4/site-packages',
 '/usr/local/lib/python2.4/site-packages',

[etc...]

I just added this code to the main ipython starter script:

# Start by cleaning up sys.path: Python automatically inserts the script's
# base directory into sys.path, at the front.  This can lead to unpleasant
# surprises.
import sys
sys.path.pop(0)

Now, the front of sys.path is identical for a plain python and an
ipython shell.  The only difference is that under ipython, the very
last two entries are:

'/home/fperez/usr/lib/python2.4/site-packages/IPython/Extensions',
 '/home/fperez/.ipython']

which don't exist for plain Python.  I don't see these as a big problem, though.

If others disagree, let us know.

Cheers,


f