Comments on: Python Package Distribution http://www.softimageblog.com/archives/18#utm_source=rss&utm_medium=rss&utm_campaign=python-package-distribution People and thoughts behind Softimage in production... Fri, 23 Jul 2010 12:23:34 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Patrick Boucher http://www.softimageblog.com/archives/18/comment-page-1#comment-38 Patrick Boucher Tue, 05 Apr 2005 23:08:11 +0000 http://www.xsi-blog.com/?p=18#comment-38 I agree that the .pth files are a great way to alter the Python search path, but as someone who is distributing your script to a wide audience, you don''t have control over your user''s .pth files. The idea was to find a way to give a script that relies heavilly on external custom libraries to a non technical user. A user who might not have the expertise (or rights for that matter) to alter his Python path. If that user can''t add .pth files or alter an environment variable due to rights restrictions can we still give him tools that are built on a library with little to no configuration work on his behalf? I agree that the way I described above if far from optimal but I haven''t had time to dig any deeper. I agree that the .pth files are a great way to alter the Python search path, but as someone who is distributing your script to a wide audience, you don”t have control over your user’’s .pth files.

The idea was to find a way to give a script that relies heavilly on external custom libraries to a non technical user. A user who might not have the expertise (or rights for that matter) to alter his Python path. If that user can”t add .pth files or alter an environment variable due to rights restrictions can we still give him tools that are built on a library with little to no configuration work on his behalf?

I agree that the way I described above if far from optimal but I haven”t had time to dig any deeper.

]]> By: Bernard Lebel http://www.softimageblog.com/archives/18/comment-page-1#comment-36 Bernard Lebel Tue, 05 Apr 2005 20:59:25 +0000 http://www.xsi-blog.com/?p=18#comment-36 The .pth file approach is, imho, BY FAR the easiest way to deal with the PYTHONPATH issue. Just drop a text file with a .pth extension into the Python root directory (ie: C:\Python24) that contains the path to the module of your choice, and there you go, you can import directly the scripts in that directory without naming any directory. After that, the only thing you need to traverse down subdirectories is to separate directory names with a dot in your import statement: import subdirectory1.subdirectory2.myModuleFile Wich is the same as, on Windows: import \subdirectory1\subdirectory2\myModuleFile.py I do have a question though, regarding the __init__.py files. Has anyone here manage to assign subdirectory globals through init files? If I try to create an XSIApplication object or assign a name to the XSI constants in the init file, the modules of this directory do not get them.... so I have to assign them in every module. Cheers Bernard The .pth file approach is, imho, BY FAR the easiest way to deal with the PYTHONPATH issue. Just drop a text file with a .pth extension into the Python root directory (ie: C:\Python24) that contains the path to the module of your choice, and there you go, you can import directly the scripts in that directory without naming any directory.

After that, the only thing you need to traverse down subdirectories is to separate directory names with a dot in your import statement:

import subdirectory1.subdirectory2.myModuleFile

Wich is the same as, on Windows:

import \subdirectory1\subdirectory2\myModuleFile.py

I do have a question though, regarding the __init__.py files. Has anyone here manage to assign subdirectory globals through init files? If I try to create an XSIApplication object or assign a name to the XSI constants in the init file, the modules of this directory do not get them…. so I have to assign them in every module.

Cheers
Bernard

]]>