kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 24/06/2017 à 22:47, Simon Küppers a écrit :
> Hi,
> 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?)


Hi Simon,
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.

Sure.
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
eeschema/pcbnew scripts)

Thanks for your interest in Kicad.

> 
> Best Regards
> Simon


-- 
Jean-Pierre CHARRAS