kicad-developers team mailing list archive
Mailing list archive
Re: [PATCH] Fix wrong directory building for python plugins
Le 24/06/2017 à 22:47, Simon Küppers a écrit :
> Just my 2 cents following down below
>> I committed your patch, and added the handling of broken python scripts in subdirs, and handling of
>> non python subdir (like subdirs containing .xsl files only)
>> Please test it.
> Is it in the master branch of KiCad (i.e. can I test it by updating from
> the nightly ubuntu PPA on launchpad by jsrenaud?)
It is in master branch, so it should be available now (or soon) in nightlies.
>> I had issues because I tested your patch (that was not broken) on a Window install, having subdirs
>> in <kicad>\share\kicad\scripting\plugins.
>> All scripts are working, but all scripts are not python scripts.
>> These subdirs have subdirs and contain also .xsl scripts.
> May I ask why the kicad scripting directory contains xsl scripts?
>> I am still thinking the current way to handle pythons scripts in subdirs is really broken because:
> I don't agree at all
>> - subdirs in subdirs are not handled: this is a heavy limitation.
> They are handled as they should be: private to a "complex style plugin"
> (as described by the plugin documentation I wrote). If you add subdirs
> to such a plugin, you can import it yourself within your plugin using
> "from <subdir> import <stuff>".
> And that is, what it should do. What it should not do is scan deeper
> than one level for plugins.
>> - subdirs containing .xsl scripts are not smartly handled
> May I ask what they are for?
<>share/kicad/scripting/plugins and subdirs contains scripts for Pcbnew and eeschema.
.xsl scripts and some .py scripts are used by Eeschema to create BOM or netlists.
Therefore, *do not expect* folders:
<>share/kicad/scripting and <>share/kicad/scripting/plugins
contain only loadable python scripts for Pcbnew.
This is the main reason I said trying to load *blindly* a subdir is a bug.
(You can see in <sources>/scripting/kicadplugins.i the code to load plugins (this is a python code) )
>> - the need to add and configure __init__.py in subdir is for now a workaround, but not really
>> acceptable for most of users, who just copy pythons scripts in a suitable subdir (the natural way to
>> add and manage pythons scripts)
> I don't get you. Why is it a workaround?
> Why do you want to organize the plugin into multiple subdirs? This
> organization in no way translates to any structure within Pcbnew (i.e.
> everything gets added to the Tools->External Plugins Menu without
> hierarchy) and would be of very limited use.
This is not true:
- .py files are not necessary scripts for Pcbnew, they can be for eeschema.
- In pcbnew we have already a hierarchy: action plugins are shown in main menu, and footprint
wizards are shown in the wizard footprint frame.
and allowing an user to add *easily* personal or downloaded python plugins inside a subdir of
~/.kicad_plugins should be a good an reasonable feature.
>> I'll be really happy if someone could have a look into this loading mechanism, and find a better way
>> to load python scripts (Remember I have a poor knowledge of Python).
> I guess first we have to really agree on how we want the loading
> mechanism to work, what features it should or should not have.
Because files in share/kicad/scripting can be used by Eeschema and Pcbnew ( perhaps later by Kicad
manager) a minimal filtering in python loading mechanism will be welcome.
Currently scripts used inside eeschema are scripts run from a command line.
But one day, eeschema (and perhaps Kicad manager) will have a python script loading mechanism.
Changes in python script loading mechanism should take in account this constraint.
Note also the need of a minimal filtering happens in any application, when this application grows:
For instance: at the beginning of Kicad, libraries (symbols and footprints) were small and not numerous.
No filtering and dir + subdirs was needed, for instance in CvPcb.
Later, filtering was added (in Cvpcb, Eeschema and Pcbnew) to be able to manage hundred of libraries
and tens of thousand of items.
I do not expect thousand of scripts, but be sure this problem exists for scripts (at least filtering
Thanks for your interest in Kicad.
> Best Regards