> 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
something
>> that we want to support. If the goal is to share code, then perhaps
the
>> code that is worth sharing should be factored out into a Python
module
>> 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
        this
        functionality in mind, as they are designed to be run always in
        an
        independent process (hence they may do initialization which
        confuses
        the calling program, or vice versa); there is no modification to
        GIMP
        which could permit that, it is a logistical problem not a
        technical
        one.
        
        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*
        directory
        belonging to the specific user, which the installation of the
        plugin
        package could put modules into.
        
        We could further postulate that the normal python modules
        directory
        should be the destination of modules that do not require GIMP
        running
        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
        example,
        pydoc and the general help() facility get confused because the
        imports
        of gimp modules fail.. so you can look up a specific module, but
        not
        search.)
        
        * I realize 'modules' is a term already used in the gimp
        directory
        structure. This is meant as a placeholder for something
        else...python-modules?

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
experimentation.

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.

Thanks

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Reply via email to