On Sat, Dec 5, 2009 at 12:22 AM, Andrew Dalke <dalke@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: [extensions] 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 Regards Tarek