kicad-developers team mailing list archive

[Miguel Ángel Ajo <majopela@xxxxxxxxxx>]

Well, exposing all we have in C++ is going to need some time.

I understand the policy, which is in place for two reasons:

1) a resource limitation issue,
2) avoid introducing regressions

but in this case I believe the addition of new python objects exposed via the
API layer as we go is  

a) quite orthogonal to all the other code kicad (no inducing regressions) ,  and  
b) I’m volunteering to do it.

So, if we introduce a first version, and we find that acceptable, I would like to
request for an specific exception on this.

Do I make sense? (I of course, could be missing other implications).


I could have an initial version available in ~1 weeks (parameters normalized,  
etc…), but not all the important pcbnew bits would be exposed, that needs more time,
and IMHO it could be added incrementally.


Miguel Ángel Ajo


On Friday, 13 de March de 2015 at 14:45, Wayne Stambaugh wrote:

> On 3/13/2015 7:54 AM, Miguel Ángel Ajo wrote:
> >  
> > I’ve been pushing a bit lately on the kicad-python Piers started,
> > trying to make everything as consistent as I can, documented [1],
> > and code as easy to type and tested as possible [2] [3] [4] [5].
> >  
> > My intention was to get this for the stable release, together with python,
> > but, given the close deadline, I’m unsure if it’s going to be better to
> > merge it not
> > for this but for the next stable version.
> >  
> > One approach could be to do a quick review of the current API interface,
> > merge it now, and keep gradually merging back new objects exposed via
> > the new
> > API (I could do the backports), and automated stable builds could help
> > there,
> > the changes are quite orthogonal to the whole kicad code, so they may not
> > bring regressions.
> >  
>  
>  
> The official KiCad release policy[1] is no feature back ports. Only
> critical (crash and/or data loss) bugs are to be fixed in the stable
> branch due to resource limitations. So if you want to get this in the
> stable release, you will have to do it soon.
>  
> [1]
> http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/md_Documentation_development_stable-release-policy.htmlhttp://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/md_Documentation_development_stable-release-policy.html
>  
> >  
> > My main concerns are nits:
> >  
> > 1) Making parameters consistent across all the exposed functions.
> >  
> > pos vs position, ref vs reference, etc...
> >  
> > 2) Making parameter ordering consistent across exposed functions.
> >  
> > Opinions/Thoughts?
> >  
> >  
> > [1] http://ci.kicad-pcb.org/job/kicad-python/ws/doc/build/html/index.html
> > [2] https://github.com/KiCad/kicad-python/blob/master/tests/unit/pcbnew/test_pcbnew_board.py
> > [3] https://github.com/KiCad/kicad-python/blob/master/tests/unit/pcbnew/test_pcbnew_module.py
> > [4] https://github.com/KiCad/kicad-python/blob/master/tests/unit/pcbnew/test_pcbnew_drawing.py
> > [5] https://github.com/KiCad/kicad-python/blob/master/tests/unit/test_kicad_point.py
> >  
> > Miguel Ángel Ajo
>  
>  
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx (mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx)
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>  
>