[wingide-users] Changing Python Path from Script

[Michael Foord]

Hello Vania,

Thanks for the suggestion.

We now have a working script for running our programs with our custom 
executable. This script always sets the current directory to the main 
directory so that all the imports work fine.

What I need to do is set the 'Python Path' associated with the current 
project, so that Wing can do autocomplete and tooltips for our code.

All the best,

Michael Foord
http://www.voidspace.org.uk/python/articles.shtml

Vania Smrkovski wrote:
> Don't know if this will help you, but in my project, I have 
> everything, the whole namespace of the importable modules, and the 
> applications (like your unit tests) two levels under the root of the 
> namespace, which I call "pandora".  Since my applications are below 
> the root of the namespace, I had to solve the same problem you do with 
> your unit tests.  So in each application mail file, I include the 
> following section of lines toward the top of the file:
>  
> if __name__ == '__main__':
>     """Apps, as a namespace, is part of the code namespace, so the 
> pandora
>     namespace will need to be dynamically added."""
>     thisPath = []
>     thisPath = os.path.abspath(os.path.curdir).split(os.sep)
>     while thisPath.pop() <> 'pandora':
>         pass
>     thisPathString = os.sep.join(thisPath)
>     sys.path.append(thisPathString)
>  
>  
> This enables me to take the current filepath as a string and split it 
> using the current system's directory separator and pop off each 
> directory that isn't the root of the project's name space, at which 
> point I just rejoing and add it to sys.path.
>  
> Let me know if you find this useful. I've never tested it on other 
> machines, though as you can see I made an attempt to make it 
> cross-platform.
>  
> Vania
>
>  
> On 1/13/07, *Michael Foord* <fuzzyman at voidspace.org.uk 
> <mailto:fuzzyman at voidspace.org.uk>> wrote:
>
>     Wingware Support wrote:
>     > On Sat, 13 Jan 2007, Michael Foord wrote:
>     >
>     >> All our imports are absolute imports based on the directory of
>     our main
>     >> script. This means that the Python path needs to be :
>     >>
>     >>     Directory of main script
>     >>     Main Directory/Python24
>     >>
>     >> We need this setting for autocomplete to work.
>     >>
>     >
>     > Maybe this is useful in crafting a work-around for now:
>     >
>     > As John said, the dir of the main script should be added
>     > automatically so nothing should be needed here.
>     How ?
>
>     If I load the file :
>
>        c:\Checkout\Main\UnitTests\SomeTest.py
>
>     How is 'Main' automatically added to the Python Path ?
>
>     >   Also, the
>     > location of the main debug file (as set from Debug menu) is
>     > stored in the project as a partial path, relative to the project
>     > location, so it should work when checking things out to different
>     > locations.
>     >
>     So every time we do a new checkout we need to create a new project
>     file.
>
>     This is what I meant about dynamically creating/modifying project
>     files.
>
>     We could solve this by having a project file in the main directory
>     - but
>     that means polluting the main directory of our repository. This isn't
>     out of the question.
>
>     It still doesn't solve the problem of when we are working on two
>     branches.
>
>     Say we have a file from a modified branch / checkout. We want to
>     simultaneously load the same file from a fresh checkout to test how
>     performance compares. Having a script that can switch the Python Path
>     based on the location of the current file will solve that.
>
>     > For the second element, what about using an environment variable?
>     > In project and file properties, anything in the form $(ENVNAME)
>     > is expanded out from the contents of the environment.
>     >
>     > So it should work to define the Python Path element as
>     > $(MAINDIR)/Python24 and setting MAINDIR environment variable from
>     > the command or a shell script / batch file before launching Wing
>     > (the script/batch file could of course also launch Wing and open
>     > the project)
>     >
>     > This isn't ideal, but maybe it'll help...
>     >
>     It's not bad - if my script changes the environment variable
>     appropriately then will wing switch to using the new value of the
>     environment variable ? My guess is not, but at least I can switch the
>     value at the command line and launch a new instance of Wing from the
>     command line which *will* use the changed value.
>
>     All the best,
>
>
>     Michael
>     http://www.voidspace.org.uk/python/articles.shtml
>
>     > - Stephan
>     >
>     >
>
>     _________________________________________________
>     Wing IDE users list
>     http://wingware.com/lists/wingide
>
>