> On Tue, Mar 2, 2010 at 2:58 PM, Sven Neumann <s...@gimp.org> wrote:
>> On Tue, 2010-03-02 at 08:01 -0500, lloyd konneker wrote:
>> I wonder if importing a plug-in from another plug-in is really
>> that we want to support. If the goal is to share code, then perhaps
>> code that is worth sharing should be factored out into a Python
>> that the plug-ins can import.
> Every Python program is also able to be a python module that plug-ins
> can import. We should preserve this feature of the language.
> (For example, one can implement an app with a comand line interface,
> and then just add a GUI in another file that uses the functions
> defined on the stand-alone first file).

David Gowers wrote:

        I've considered this problem a fair bit, and my opinion is that
        if you
        want this functionality, you should simply guard your
        register()s. We
        cannot safely 'co-opt' python plugins that are not written with
        functionality in mind, as they are designed to be run always in
        independent process (hence they may do initialization which
        the calling program, or vice versa); there is no modification to
        which could permit that, it is a logistical problem not a
        Allowing python plugins to make separate modules available on
        installation, similar to Sven's suggestion, seems to me the most
        practical suggestion. This means we would add two items to
        sys.path --
        one the site modules* directory, and the other the modules*
        belonging to the specific user, which the installation of the
        package could put modules into.
        We could further postulate that the normal python modules
        should be the destination of modules that do not require GIMP
        in order to function, and only GIMP-requiring modules would be
        installed in it's modules* directory.
        I make this distinction because there are various good reasons
        not to
        install gimp-dependent modules in the global namespace (for
        pydoc and the general help() facility get confused because the
        of gimp modules fail.. so you can look up a specific module, but
        * I realize 'modules' is a term already used in the gimp
        structure. This is meant as a placeholder for something

I agree with Joao S. O. Bueno and disagree with David Bowers.

Its better to make plugins meet the normal expectations of Python
programmers (you can import any Python file to use pieces of it) than to
add new conventions and directories for shared Python plugin code.
Simpler is better?

Often, authors don't plan their code will be useful to others.  It's
just serendipity.  If authors don't plan to share code and put it in
these new directories, it thwarts serendipitous reuse and

It is inconsistent for a duplicate call to register() to be harmless
with a warning while a duplicate call to main() is fatal.

Also, new conventions and directories does not solve my wish to call
pydoc on plugins (which is not very important.  I hope to download a
prototype Inspect plugin to gimp registry soon.)  But it illustrates
that you can't always anticipate what people will want to do.


Gimp-developer mailing list

Reply via email to