I can’t tell if you are asking about how to visually append items to a
list, as in your example, or whether you are asking about how to build a
plug-in architecture?
I’ll assume you mean the latter as it is the more difficult aspect.
Importing multiple times as Justin said is a good point about many of the
gotchas you might experience while working on this. It’s possible you might
find similar problems with reloading a module and using execfile as well;
for example imports taking place *within* your script are typically cached
like any other import, which means you’ll need to somehow either keep track
of those imports and make sure they happen once per script, or count on the
fact that it may happen.
Depending on the nature of your scripts, a safe method of running each
script in isolation, without worrying too much about side-effects or paths,
might be to subprocess each invokation.
import osimport sysimport subprocess
for script in os.listdir("."):
subprocess.call([sys.executable, script])
At this point, no amount of nested imports, side-effects or messing about
with PYTHONPATH can throw your execution mechanism off guard!
The next step might be to append each result of os.listdir to your GUI.
# Using QListWidget with QListWidgetItemfor script in os.listdir("."):
item = QtGui.QListWidgetItem(script)
self.mylistwigdet.addItem(item)
Then, once hitting “run”, you would do as above; loop through each item and
run each script.
for i in xrange(widget.count()):
item = widget.item(i)
script = item.text()
subprocess.call([sys.executable, script])
That should do it!
On 27 December 2015 at 14:31, Justin Israel <[email protected]> wrote:
>
>
> On Sun, 27 Dec 2015 6:06 AM Rudi Hammad <[email protected]> wrote:
>
>> Hey marcus,
>> The idea is to do that but using a widget that lists scripts that you can
>> add or remove in a UI.
>> What is the diference between __import__ and just import? Both excute the
>> script right?
>>
>
> __import__ is the same as the import statement, but lets you do it more
> dynamically with names as strings that you know only later at runtime. But
> just like the normal import, if the module has already been imported, then
> importing it again will have no effect unless you reload it.
>
> But importing doesn't work if the module have classes and methods. You
>> should import the module, create a class object and then
>> theClassobject.myMethod()
>> Am I right?
>>
>
> You have to determine how these "scripts" will be structured to make them
> usable by your application. It is kind of like a plugin system. They are
> "scripts" if they are directly runnable. Though usually it's a bad idea to
> write python modules that execute purely by importing. Unless these scripts
> are only for your app, and no one else.
> Another way is to make them all define a consistent interface. You can
> require that an action module for your app define a specifically named
> function (or functions). Then you can import them and run the functions
> entry point to launch the action.
>
> Maybe like this...
>
> #---
> ACTION_NAME = "My action"
>
> def run():
> print "running %r" % ACTION_NAME
> #---
>
> You can use the imp module to do a lower level import which somewhat
> bypasses the sys.modules lookup and lets you repeatedly load source code :
> https://docs.python.org/2/library/imp.html
>
>
> Anyway,back to the main question that was about adding scripts un the Ul
>>
>
> That bit would be a matter of deciding where you require that action
> scripts be stored in the first place. Maybe you check a certain directory
> (like Marcus suggested). Maybe you look at an environment variable that
> people can set to change the action location or specify multiple ones,
> separated by a ":"
>
> Once you know your list of action modules, you can load them, read their
> description names and display them in your list, while associating them
> with the module that should be loaded.
>
>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Python Programming for Autodesk Maya" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/python_inside_maya/a84761fe-4ffb-461a-8bba-eec43d22fc5c%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Python Programming for Autodesk Maya" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3tNrpGH3POxtv0_PhbtsNfkWM8KVn6WRZe46frJfsbZA%40mail.gmail.com
> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA3tNrpGH3POxtv0_PhbtsNfkWM8KVn6WRZe46frJfsbZA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
*Marcus Ottosson*
[email protected]
--
You received this message because you are subscribed to the Google Groups
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODKAMSKzW%3DUQ21DmC6TsUQnuzT2%2BBD0UN4774kuT5pWkA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
