Importing moduals/scripts

Coding
1

So at work i’m developing a way for us to push out tools/plugins to the team as a whole. I actually have the system up and running and it’s completely dynamic except for the topic i’m about to talk about. On start up Maya checks the local folder against a folder on the server and checks to see if they are different and handles and copying down files/dirs that are needed as well as the deleting of old plugins that we delete on the server. The system is flexible enough that users can create custom shelves of all the plugins and we can re organize the folders in the back end without breaking the shelves of all the users. The plugins are accessed through a drop down menu in Maya’s main interface and we can add sub folders into the system and plugins freely without messing with the code. We can also arrange the order at which menu items and plugins can be displayed through a simple numbering system of the folders.

This is all working fine until I get to making plugins, when they import a module in their folder, dynamic as well. So when I start moving the plugins folder around the root directory, if I have an imported module that I created the path for, the imported modules path in the plugin script is now wrong at that point. I already have a way of getting the proper path info to the plugin through my menu setup. I’m having issue with the import of the module and accessing classes with in that module.

so If the standard for importing a module’s class

from fileName import className

and the import way that i’m using looks like.

className = __import__("folderN.folderN.folderN.fileName", {}, {}, ["className"])

But with that method I loose the ability to just call on that class name like I can with the regular from import method. I got around that by doing

cassName = className.className

but this is a rather ugly method and i’d prefer to be able to just import and call on the name without doing that extra step. I do not know this import method very well and I know i’m missing some things with it.

Am I just going about this import process the wrong way? Is there a way to make it look into the local directory for the plugin without appending to maya’s paths that way i can just do the regular way of importing method without a weird path that has to change anytime I move the plugin?

2

Hi! Apologies if I am missing something, but are you modifying your PYTHONPATH at all?

3

I do that to get maya to the scripts directory but I don’t mess with it for the individual scripts

4

Speaking only to the usage of import.

I’m not sure why you think that is ugly; it is the correct usage of import. How are you expecting to be able to use it?
The import method leaves a lot of the error checking and attribute assignment to the import statement (like it won’t error if the attributes in fromlist don’t exist), so you’ll naturally have to do that yourself.


module = __import__(modulePath, fromlist=[attributeName])
try:
    attribute = module.getattr(attributeName)
except AttributeError:
    # uh-oh

If you’re using that code chunk a lot you could wrap it into your own import method (or if you’re using 2.7+, there is an importlib module, though I have no experience with it and I think you’ll still have to do the attribute assignment)

5

Two things:

  1. From a code standpoint, have you considered creating these things as submodules to packages that are dynamically populated at load time – sort of the way os.path loads os.posixpath or os.ntpath or whatever without changes to the calling code? That way you can present a stable front end to user code while swapping things around in the backround and keeping all the complexity in one place (in the init code of your big modules). Basically the public face of the module would be a stable name but the contents of the name could be swapped based on loading conditions. I’d be careful about relying too much on directory structures for this – it can create a lot of variability on the user side if there are leftover files or things-that-should-have-been-deleted lying around.

  2. Looked at imp? ?

6

[QUOTE=Theodox;21163]Two things:

  1. From a code standpoint, have you considered creating these things as submodules to packages that are dynamically populated at load time – sort of the way os.path loads os.posixpath or os.ntpath or whatever without changes to the calling code? That way you can present a stable front end to user code while swapping things around in the backround and keeping all the complexity in one place (in the init code of your big modules). Basically the public face of the module would be a stable name but the contents of the name could be swapped based on loading conditions. I’d be careful about relying too much on directory structures for this – it can create a lot of variability on the user side if there are leftover files or things-that-should-have-been-deleted lying around.

  2. Looked at imp? ?[/QUOTE]

I’ve actually got it up and running I completely forgot that once I establish the plugins import path that I handle dynamically through the system that I can just call on modules that are already inside of that folder without providing the same path that it took to get to that folder. so instead of having import folderN.folderN.folderN since i’ve already done that when calling on the plugin.py file I can just call on the other files as i normally would. Thanks for all the help!

I’ll take a look at imp

7

Have to say I discovered imp as while ago when I was trying to dynamically import modules at a folder level for the Red9 PoseSaver. I wanted to be able to import and modify on the fly where a given module came from, you select a folder, I scan it for a given python module and force that to be the active import for that folder only. imp worked really well for this type of thi