On 03/11/2013 10:32 AM, Adam Wolf wrote: > > 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? >
It gets bad when you guess wrong. At this point I am resigning from the conversation. I worked until 3:30 AM last night on this shit, and in the last month I worked 3 weekends on providing python a-mingw-us. The first time I stuggle to edit a python script, who the hell knows what will happen. Let the package maintainers figure it out, make it easy for me please. > On Mar 11, 2013 10:25 AM, "Miguel Angel Ajo Pelayo" > <miguelan...@nbee.es <mailto: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 <tel:%2B34911407752> > skype: ajoajoajo > > On 11/03/2013, at 16:20, Adam Wolf > <adamw...@feelslikeburning.com > <mailto: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 <mailto: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 <http://www.nbee.es/> >> +34911407752 <tel:%2B34911407752> >> skype: ajoajoajo >> >> On 11/03/2013, at 15:33, Dick Hollenbeck <d...@softplc.com >> <mailto: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
