> On Tue, Mar 2, 2010 at 2:58 PM, Sven Neumann <sven@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
