kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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"
> <miguelangel@xxxxxxx <mailto: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 <tel:%2B34911407752>
>     skype: ajoajoajo
>
>     On 11/03/2013, at 16:20, Adam Wolf
>     <adamwolf@xxxxxxxxxxxxxxxxxxxx
>     <mailto: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 <mailto: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 <http://www.nbee.es/>
>>         +34911407752 <tel:%2B34911407752>
>>         skype: ajoajoajo
>>
>>         On 11/03/2013, at 15:33, Dick Hollenbeck <dick@xxxxxxxxxxx
>>         <mailto: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.
>>
>