#5 yapsy and global state

[Alois]

Hello,

recently I refactored my program to contain a global state class. That is just a module that contains a class that stores app-wide config.
My setup has the following structure:

- appdir/
  - __init.py__
  - MyState.py
  - MyApp.py
  - IPlugin.py
  - plugins/
    - __init.py__
    - aplugin.py
    - aplugin.yapsy-plugin

I noticed the following: importing MyState from the plugin in the way

import appdir.MyState

preserves the state of my app and everything works just fine. But if I use

import MyState

it seems that the state is just empty, i.e., another namespace is created somehow.
This is strictly speaking not a bug I guess since I can just use the former.

But in the last time I have problems with imports and pyinstaller because I want to pack a binary for windows users.
To this end I need to understand things in more detail.

Best,

Alois

[Thibauld Nion]

Hello,

This is expected and this is not related to yapsy, but to the way Python imports modules.

What basically happens is just what you say: both imported modules are considered as belonging to different namespaces.

This is a typical caveat when mixing a package-style import (like "import package.filename") with local import (like "import filename"), but here the situation looks a bit different. What is strange is that a plugin can "import MyState" whereas MyState.py is not sitting next to it in the "plugins" directory.

My wild guess for your packaging problem: at some point you're doing a sys.path.append(path/to/appdir) and you shouldn't do that for a package you intend to distribute (I had a similar problem in the very early days of yapsy).

[Thibauld Nion]

Ticket moved from /p/yapsy/bugs/29/

[Alois]

Ok I see thanks for the quick response.

I was wondering also because the Python docs state:

In fact, such references are so common that the import statement first looks in the containing package before looking in the standard module search path.

But if so, why is there a difference?

Concerning the packaging problem I filed a SO post.

One last question:

Would you put the interface file IPlugin in the plugin directory or in appdir?
And for the plugins, would you prefer relative imports, e.g., in the sense of PEP 0328 or absolute imports, that is, appdir.IPlugin?

You might as well close this "bug", for I have to analyze the issue in more detail.

[Thibauld Nion]

I would put th IPlugin class in the appdir as in your example. I grew a bit suspicious of relative imports several years ago (I would go for absolute ones) but thkngs have changed and predumably improved, so don't take my word for it.