Changing script's search path at install time

[Dave Angel]

On 12/19/2014 05:51 PM, Mitko Haralanov wrote:
> Hi all,
>
> I have a question regarding installation of Python scripts and modules
> using distutils that I can't find an answer to by searching through Google
> and the Python website. Hopefully, someone on this list might have ideas?
>
> I am writing a Python app, which I would eventually like to install using
> disutils. The app has the current tree strucutre:
>
> <root>
>    |----- myapp.py
>    |----- modules/
>                 |------  lib/
>                           |------  __init__.py
>                           |------  mymodule1.py
>                           |------  mymdule2.py
>                 |------- cmds/
>                           |------  __init__.py
>                           |------  cmds1.py
>
> Naturally, in order for my app to properly import the modules, currently it
> uses the following code:
>
>      import modules.lib.mymodule1
>      import modules.lib.mymodule2
>      import modules.cmds.cmds1

>
> However, when the app gets installed, I would like to install the modules
> to /usr/lib64/pythonX.Y/site-packages/myapp. I know that I can do this by
> using the "package_dir" argument to the "setup()" function in
> distutils.core.
>
> To make development easier I would like to be able to run the myapp.py
> script from the development directory,

Nonsense.  It should have the same structure on your machine as your 
customer will have.  So move the modules to where they're really going 
to be installed, and correct the imports until it tests correct.

> which means that the import
> statements have to remain as they are. The issue is that when the script is
> installed, the import statements will not work anymore since the directory
> name has been changed from "modules" to "myapp".
>
> My problem is that I can't figure out how to modify the myapp.py script to
> switch from "modules.lib.mymodule1" to "myapp.lib.module1" at install time.

Bad idea.

> Does anyone have any useful hints?
>

Yes, develop in the same environment as the customer is going to run. 
If for some reason you cannot, then TEST in the same environment as the 
customer is going to run.  If this confuses your source control, or some 
such other problem, deal with it there.  maybe use symlinks, or use a 
script to "install" the stuff.



-- 
DaveA