[IPython-dev] Extensions: decisions on loading them and API (thoughts from R. Kern's branch)
Barry Wark
barrywark at gmail.com
Mon Mar 16 17:01:36 EDT 2009
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
>
More information about the IPython-dev
mailing list