kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

For me, the most reasonable solution sounds like providing both options, 
being able to enforce a user-local destination for python modules/libraries,
or a system wide standard one.

In development, or single user installations, first is better, for apt-get install
or equivalent system-wide installations, the second sounds correct.

Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 11/03/2013, at 16:20, Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx> wrote:

> If we store all the python modules in a user's home directory, how do they get there?  Does kicad put them there, or does the installer?
> 
> While we should provide the python modules like footprint_wizard.py for download, we cannot easily provide the swiggy modules like pcbnew.py for download, because they depend upon both the kicad source and state on the user's system.
> 
> If the installer is putting them there, I hope we don't have a situation where the dll-like swiggy python modules are only in one home directory.  This could create issues if you delete your dotfiles or another user wants to use Python support.
> 
> Adam Wolf
> 
> On Mar 11, 2013 9:39 AM, "Miguel Angel Ajo Pelayo" <miguelangel@xxxxxxx> wrote:
> 
> That looks quite much to the wrapping I had to do in MacOX to avoid static linking, 
> where it's uncommon for normal users to put new libraries in the system paths:
> 
> I rename pcbnew to pcbnew.bin and put the loader as "pcbnew", same for all the other apps,
> it just builds a pointer to the libraries, the python path, and kicad stock libraries, and then
> boots the app itself.
> 
> #!/bin/sh
> 
> 
> # this is script wraps the original binary application, 
> 
> # and sets the library paths just before launching
> 
> 
> DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
> 
> 
> export KICAD_APP=$DIR/../../../kicad.app
> 
> export KICAD_DATA=$DIR/../../../data
> 
> 
> # let the apps find the libraries at startup
> 
> export DYLD_LIBRARY_PATH=$KICAD_APP/Contents/Frameworks:$DYLD_LIBRARY_PATH
> 
> 
> # let python scripting find our modules
> 
> export PYTHONPATH=$KICAD_APP/Contents/Frameworks/python2.7/site-packages/:$PYTHONPATH
> 
> 
> export KICAD=$KICAD_DATA
> 
> 
> $DIR/`basename $0`.bin $*
> 
> 
> 
> Miguel Angel Ajo
> http://www.nbee.es
> +34911407752
> skype: ajoajoajo
> 
> On 11/03/2013, at 15:33, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
> 
>> For the 4th time, yes.  And it would not bother me at all to be
>> different from a decade of other python users, but like blender users.
>> 
>> I am happy to be different, when I know I am helping myself.
>> 
>> Maintaining a distinction between two categories of kicad python
>> modules is a low priority to me.
>> 
>> For linux users, the installer can set PYTHONPATH on the commandline,
>> and this can be done in a desktop launcher (icon or menu):
>> 
>> 
>> $ PYTHONPATH=<writeable-convenient-dir>:$PATHONPATH  pcbnew
>> 
>> $ PYTHONPATH=<writeable-convenient-dir>:$PATHONPATH  kicad
>> 
>> 
>> I believe these settings would last as long as the program is running,
>> only.  Which is about what we want.
>> 
>> Might need to to put sh in front of that.
>