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" <miguelan...@nbee.es> 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 <adamw...@feelslikeburning.com> 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" <miguelan...@nbee.es> > 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 <d...@softplc.com> 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. >> >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
