an0malaus opened this issue on Nov 25, 2011 · 8 posts
an0malaus posted Fri, 25 November 2011 at 8:23 AM
I'm running Mac OS X 10.7.2 and Poser Pro 2012 and have run into some problems with BagginsBill's parmatic and matmatic scripts in the form of python "No module named
Searching the Python 2.7 documentations informs me that modules can either acquire their name from a filename, e.g. parmatic.py or from a directory name. In this case the final directory of the "/Users/Shared/Poser Pro 2012 Content/Runtime/Python/parmatic" path. Python modules can also be part of a package, which may be referred to as simply a named directory in which other python modules reside. But Poser's python can't seem to find the parmatic module. There is no parmatic.py (or parmatic.pyc) file in the parmatic directory. The file that contains the parmatic module is called init.py which implies to me that parmatic is a python package as opposed to just a simple module as far as python's concerned (please correct me if this is wrong). The other piece of information which seems almost, but not quite sufficient in this situation, is that the directory in which a python script is contained is automatically added to the path when that script is executed manually (or in this case, via a Poser python script button). We can see that this is the case by looking at the sys.path, which does include /Users/.../parmatic as shown in the screenshot. Yet python still can't find the parmatic module.
Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.
an0malaus posted Fri, 25 November 2011 at 8:28 AM
OK, for my second attempt, I tried copying init.py to parmatic.py. Lo, and behold, it worked, yet parmatic, which appears identical in all respects to other python packages should not have needed that extra step otherwise it would have been distributed that way; and what would the point of the python standard init.py have been in that case? Something else must be missing.
Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.
an0malaus posted Fri, 25 November 2011 at 8:45 AM
So, it seems for simple python modules (filename = module name + .py) which contain all their code in one file, just executing the
For python packages, however, executing a python script within the package directory itself doesn't seem to be sufficient for python to locate the package. Python needs to have the parent directory which contains the package (directory) added to the sys.path.
Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.
PhilC posted Fri, 25 November 2011 at 9:02 AM
Did the Matmatic instructions say to install it to your Poser application folder or to a remote Poser library such as your Poser Pro 2012 Content folder?
millighost posted Fri, 25 November 2011 at 9:34 AM
Quote - ...
So, it seems for simple python modules (filename = module name + .py) which contain all their code in one file, just executing the
.py is enough to add its path automatically to sys.path and allow everything to be found. For python packages, however, executing a python script within the package directory itself doesn't seem to be sufficient for python to locate the package. Python needs to have the parent directory which contains the package (directory) added to the sys.path.
Yes, this is essentially true, but not the whole truth; python, when importing modules, does not only look within the sys.path, but it looks in the path the currently active module was loaded from, too. So in general you can indeed just simply switch to the directory, where the module is in, and then import it. In the special case of parmatic, however, this does not work, because the parmatic module is "self aware", so to speak. I.e. it contains a statement like "from parmatic import ParmaticActor", where a "import ParmaticActor" would normally suffice. Not directly a bug, but an inconvenience that could likely be fixed in an update (ask bagginsbill).
In general, there are two kinds of modules: a) files and b) directories containing an init.py file. The general rule holds: the sys.path must contain the module to load (can be either the directory or the file). Looking at it this way, there is not much difference between modules in packages or modules in files IMO.
an0malaus posted Fri, 25 November 2011 at 10:17 AM
Now on to matmatic; A search of the non-compiled module files finds in compile.py exactly what was needed to avert the problem that parmatic suffered from: adding the directory containing the directory (called matmatic) where compile.py resides to the sys.path so that the rest of the modules in the matmatic package can be located.
Yay! Matmatic never complains about not being able to find its own modules! Good work!
Matmatic's extensible configuration, allowing user customisations to be extracted and saving them from being overwritten when updates to matmatic are installed is smart and user-friendly. Specifying whole directory trees to be searched for matmatic scripts to be compiled is even available by appending a wildcard to the directory name. Terrific stuff!
Downloading a bunch of sample matmatic scripts by third parties seems like it should give a good insight into the learning process involved in getting to grips with matmatic. Wow, they all look like python scripts. Great! Couldn't be simpler. I might even learn some extra python tricks.
Oh. Wait. Someone's extracted a bit of commonly used code out of one of their matmatic scripts and is treating it just like a python module, i.e. to use a module, you need to import it so python knows where to find the classes and functions you're referring to. Let's try it. Ba-dum! Thankyou for playing :-(
Hmm. Matmatic found the module to compile because I told it to look in a certain place and all its subdirectories. Yet now there's another module not being found that exists in exactly the same directory being referred to ...
Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.
an0malaus posted Fri, 25 November 2011 at 10:45 AM
Quote - Did the Matmatic instructions say to install it to your Poser application folder or to a remote Poser library such as your Poser Pro 2012 Content folder?
Ah, that was the Zeroth thing I tried. Notwithstanding that PP2012 installation on Mac OS X offers to place the main Runtime in a shared user location rather than with the application.
The matmatic website describes placing matmatic in the "Main Runtime" under Runtime:Python(:matmatic)
Having first downloaded the Matmatic 1.4.0 script, whose zip bundle did not include the (older) documentation, I had not seen any of it. I have now looked at the older unbundled beta documentation which was released prior to Poser 9/PPro 2012. Nothing unexpected in the installation instructions there.
Verbosity: Profusely promulgating Graham's number epics of complete and utter verbiage by the metric monkey barrel.
bagginsbill posted Fri, 25 November 2011 at 1:49 PM
Parmatic is a package - so yes it is the name of a folder and has an init.py for its main module.
Parmatic made the assumption that Poser could always be expected to place its main runtime/Python folder into sys.path. Apparently PP2012 doesn't do that, eh?
I learned my lesson after that and you can see that matmatic is more clever. I had so many problems with Mac versus PC paths that I gave up on making any assumptions other than you would keep the matmatic files together in a matmatic package, and that I could find said folder and set it up in sys.path because you would be running one of the files included in the package.
You could update parmatic to do the same trick if you like. I put parmatic in the public domain, if I recall correctly.
Oh - and I used from X import Y on purpose. Doing otherwise risks picking up a module from elsewhere, although I have to admit that I used belt and suspenders. It is incredibly unlikely to accidentally pick up somebody else's module when its name has the word parmatic in it. But technically speaking, a naked "import ParmaticActor" is semantically different than "from parmatic import ParmaticActor". Particularly when "ParmticActor" could be the name of a function, versus a module, the longer form is necessary.
Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)