[Distutils] installing .py plugins to an alternate directory

Tarek Ziadé ziade.tarek at gmail.com
Sat Dec 5 01:44:58 CET 2009

On Sat, Dec 5, 2009 at 12:22 AM, Andrew Dalke <dalke at dalkescientific.com> wrote:
> I looked at the installation instructions for mercurial packages listed at http://mercurial.selenic.com/wiki/UsingExtensions . They all require hand-editing of the hgrc file. That is not what I want.

Yes, that's how it works, you can add in ~/.hgrc:

   package.spam_extension =

And mercurial will enventually do an __import__("package.spam_extension").
That's an explicit plugin system.

Setuptools entry_points are a plugin system based on discovery: you
register some code and
you can iterate on all registered code from your app.

In the next mail you are writing about entry_points this:

> I had some concerns about them. For one, all of the plugins define out-word facing web services on
> our server. If the plugins can be located in arbitrary locations inside of site-packages, how does
> the administrator know which plugins will be activated? How does the admin enable/disable a
> plugin for testing or security reasons, except by changing the entire package installation?

This means that you want to be able to *manage* and configure your
plugins, so unless you are driving
them from an explicit central configuration system like mercurial has,
you won't be able to fully control plugins,
which can lead to the limitations you are describing.

The other way is to force the plugins to be located in the same
directory as you said, but this means that
you want to allow any third-party application to install itself as a
plugin in there. Then if the administrator wants
to deactivate some plugins, what will he do ? remove the file that was
added in the special directory ?
That could make that particular plugin half-removed if it has other
files in the system. IOW if a plugin is installed
in the system, it has to be fully installed within your application if
you want full control over it.

That's why I was thinking of a configuration file, where it is easy to
control your plugins explicitely.

Of course, until we have the APIs (PEP 376) to uninstall packages
easily, it's not easy to remove an installed
project that may contain the plugin, unless it was installed with Pip.

Or, maybe you could use self-contained eggs, like zc.buildout does,
that might be the only use case for them


More information about the Distutils-SIG mailing list