Imports in a Python plugin

[Ottia Tuota]

Hello!

I have been writing some plugins for Gimp. I plan to share them soon since I believe they will be useful. But I have a problem where I wish you can help me.

I explain the general situation first before making my question.

Python allows imports. I have the plugins in two Python files. (One file registrates one Gimp plugin and the other registrates two.) The files contain large common parts. The common parts are currently embedded in both files, but it would be much better if the common parts could be in separate files instead and the two plugin files would just import them.

Now you perhaps think that I might just combine everything in one big file containing three registrations. But I don't want to do that. For future development I would want to have the common parts each in its own file, and I don't like the idea of having to combine everything in one big file every time I make a new version of some part. Besides, it is likely that those common parts will find usage in some future plugins.

Now I pose my question (sorry about the lengthy explanations). Please note that I know very little about computers.

Can the following be realized somehow? Suppose we have a file A.py implementing a plugin. Another file B.py contains material that we want to be imported in A.py, for instance some object called NameDefinedInB. In file A.py we have written

# File A.py
# ---------
from gimpfu import *
import B as imported_B
...
NameInA = imported_B.NameDefinedInB
# Then NameInA is applied in A.py in some way
...


In Gimp's plug-ins folder we put A.py and B.py in the same subfolder A as follows:

plug-ins
   |
   +---A  (subfolder)
   |   |
   |   +----A.py  (file, the plugin)
   |   +----B.py  (file, to be imported in A.py)
   |
   +---some other plugin
   |
   +---some other plugin
   |
  ...
   

This is how I would like to arrange things, hoping that the stuff in B.py will be imported in A.py.

I made a little test plugin about this. I have tried it with the following three installations of Gimp (on Windows 10 64 bits):

1: Gimp 2.10.18 from gimp.org
2: Gimp 2.10.18 portable from Samj
3: Gimp 2.10.18 portable from Partha

and got the following results:

1: The test plugin does not appear in Gimp's menu.
2: The test plugin does not appear in Gimp's menu.
3: Works OK! (And a .pyc file is created.)

The test plugin is in the attached zip file in case you wish to try it. Put the whole folder import_test as a subfolder in Gimp's plug-ins folder and restart Gimp. The plugin should be found as Filters/ImportTest/Import test. If it is, click it and see if anything happens in the error console.

Any ideas? Is this supposed to work at all? Since I want to share the plugins, I need a solution that works for everybody as such. Thanks in advance!

[Ofnuts]

See attached.

Code:

Modules
├── common.py
├── module1.py
├── module2.py
├── module3.py
└── Modules.py

This contains a "main" file (Modules.py) that registers three plugins that use function in the module*.py files, while all three use code from common.py. Unzip and put the Modules directory in your plugin directory.

The trick is to retrieve the directory of installation (in "Modules") and insert it in the Python path where python looks for imports.

Remark: in Linux, macOS/OSX and other Unixen, Gimp only looks for files with the executable flag set (and only Modules/Modules.py has it). On Windows it will try to register all the *.py files, and since only Modules.py gets registered the other ones will be rerun on ebery Gimp startup.

Which bring us to why this is not such a good idea...

• If your common code evolves (and if you are a decent (read: unsatisfied) programmer this will happen) you will likely do things in your new modules that would make them incompatible with old version of plugins. Lots of explanations to your users in perspective.
  
• Of course you can have a directory for each plugin, each with its own version of the module. But this is not enforced and users got in the habit of putting everything in the same directory, directed by countless tutorials that tells them do so. 
  

So in the end it could be easier to have a small packaging utility that lumps all your code in one single file before publishing.

[Ottia Tuota]

(03-07-2020, 08:38 PM)Ofnuts Wrote: See attached.

Code:

Modules
├── common.py
├── module1.py
├── module2.py
├── module3.py
└── Modules.py

This contains a "main" file (Modules.py) that registers three plugins that use function in the module*.py files, while all three use code from common.py. Unzip and put the Modules directory in your plugin directory.

The trick is to retrieve the directory of installation (in "Modules") and insert it in the Python path where python looks for imports.

Remark: in Linux, macOS/OSX and other Unixen, Gimp only looks for files with the executable flag set (and only Modules/Modules.py has it). On Windows it will try to register all the *.py files, and since only Modules.py gets registered the other ones will be rerun on ebery Gimp startup.

Which bring us to why this is not such a good idea...

• If your common code evolves (and if you are a decent (read: unsatisfied) programmer this will happen) you will likely do things in your new modules that would make them incompatible with old version of plugins. Lots of explanations to your users in perspective.
  
• Of course you can have a directory for each plugin, each with its own version of the module. But this is not enforced and users got in the habit of putting everything in the same directory, directed by countless tutorials that tells them do so. 
  

So in the end it could be easier to have a small packaging utility that lumps all your code in one single file before publishing.

Thank you so much, Ofnuts. I shall think about this and come back then. I am no real programmer. I have much to learn, and I take your advice seriously.

[Ofnuts]

As a side note, I didn't write this example for you, I found it in my code collection, very likely because I wanted to do this like you at some point

[Ottia Tuota]

I am sure you are right. It is best to keep the development and published versions quite separate, the latter being one big file. Otherwise the users' plug-ins folders would soon be messed up. But it is a pity really.

I am not able to write such utilities, so I must do everything by hand. And if several plugins need same modules but different versions, it is all becoming rather difficult. Soon my own folder system will be messed up. But that is a smaller evil. Well, at least it keeps ones mind occupied, and that is positive.

Thanks for the help. I shall introduce my little plugins when I get them cleaned up a bit.

[Ottia Tuota]

Never mind. I was able to write such utility after all. The plugins will be published right away.