kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

Would it be bad for us to put the swiggy autogenerated stuff in a readonly,
central location, because it's not going to be modified without doing a new
cmake?  Then we put all the scripts that will be modified in a homedir?
On Mar 11, 2013 10:25 AM, "Miguel Angel Ajo Pelayo" <miguelangel@xxxxxxx>
wrote:

> 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.
>>
>>
>>
>