[IPython-dev] Extensions: decisions on loading them and API (thoughts from R. Kern's branch)

[Barry Wark]

On Sat, Mar 14, 2009 at 5:27 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi all,
>
> I was reviewing Robert's branch
>
> https://code.launchpad.net/~robert-kern/ipython/pretty
>
> which reminded me of revisiting our Extensions setup. That space has,
> over time, gotten somewhat disorganized:
>
> maqroll[Extensions]> ls *py
> astyle.py                 ipy_foo.py              ipy_signals.py
> clearcmd.py               ipy_fsops.py            ipy_stock_completers.py
> envpersist.py             ipy_gnuglobal.py        ipy_synchronize_with.py
> ext_rescapture.py         ipy_greedycompleter.py  ipy_system_conf.py
> ibrowse.py                ipy_jot.py              ipy_traits_completer.py
> igrid.py                  ipy_kitcfg.py           ipy_vimserver.py
> __init__.py               ipy_legacy.py           ipy_which.py
> InterpreterExec.py        ipy_lookfor.py          ipy_winpdb.py
> InterpreterPasteInput.py  ipy_p4.py               ipy_workdir.py
> ipipe.py                  ipy_profile_doctest.py  jobctrl.py
> ipy_app_completers.py     ipy_profile_none.py     ledit.py
> ipy_autoreload.py         ipy_profile_numpy.py    numeric_formats.py
> ipy_bzr.py                ipy_profile_scipy.py    PhysicalQInput.py
> ipy_completers.py         ipy_profile_sh.py       PhysicalQInteractive.py
> ipy_constants.py          ipy_profile_zope.py     pickleshare.py*
> ipy_defaults.py           ipy_pydb.py             pspersistence.py
> ipy_editors.py            ipy_rehashdir.py        scitedirector.py
> ipy_exportdb.py           ipy_render.py           win32clip.py
> ipy_extutil.py            ipy_server.py
> maqroll[Extensions]>
>
> The two key things we need to do, probably right after the 0.10 release:
>
> 1. Stop putting Extensions into sys.path.  This is just bad practice,
> as it pollutes people's import path with our stuff.  Users who want an
> extension can just write
>
> from IPython.Extensions import foo
>
> instead of
>
> import foo (or even ipy_foo)
>
> it's not that much more work, and much, much cleaner.
>
> 2. Have all extensions require an explicit entry point to be
> activated.  Something like
>
> from IPython.Extensions import foo
> foo.activate()  # this could take parameters, if the extension file
> provides more than one thing.
>
> I'm open to suggestions on this point, API ideas, etc.  But I have no
> doubt that the current practice of extensions automatically
> registering themselves with top-level code is a bad idea.  It means
> that their mere import has side effects, which goes counter to most
> standard python practice and can cause problems.  For example, things
> like sphinx that import all modules can be badly messed up if each
> extension starts having global side effects.
>
> Ideally, extensions could also be unloaded, so perhaps the api should
> read instead
>
> foo.load()
> foo.unload()
>
> for those that support it.  This would make the job of testing them
> much, much easier.
>
> Thoughts on the API, etc?  If we can agree on this, then at least
> Robert's current one could already be fixed for this mode of use
> before it sees public life.

+1 on making extension loading and importing more explicit. I think
load()/unload() are good, as it would also allow more dynamic
loading/unloading of extensions depending on context (ala TextMate's
bundle contexts) in the future. We could ease the transition, perhaps,
by adding a startup flag that, if set, will monkey-patch sys.path as
is done now. Again, forcing this behavior to be explicitly requested
is a good idea.

More broadly, extensions might be viewed as a plugin system. Is there
any will towards incorporating one of the many python plugin systems
instead of rolling our own? I don't know the core very well, so there
could easily be good reasons against such an approach.

-Barry

> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>