Livraison mineure de Yapsy v1.10.423

yapsyYapsy: ma petite librairie python de gestion de plugin vient de sortir en version 1.10.423[en].

Assez peu de changements en fait si ce n’est quelques ajustements suite aux remarques des développeurs du projet Nikola[en] qui utilisent yapsy pour modulariser leur projet, ainsi qu’une amélioration de la couverture de test qui est désormais visible sur[en].

  • Grazfather x

    Hi there, I use your python module and I have a problem with it. Instead of having a flat hierarchy of subtypes of IPlugin I have a tree that is a few levels deep. The problem with this is that if I, for example, have class A(IPlugin) and then class B(A), both interfaces, and then class C(B) which is the implementation, when the module is loaded and the default category is checked against, ‘B’ is considered a legal plugin because it’s a subtype of IPlugin and isn’t an IPlugin. Because, in my case, B comes before C in dir(module), then the B module is instantiated. Maybe Yapsy should look in the module for a class with a name matching the module name? I noticed, for example, if I import the module B ‘as z’ it comes later in dir() and I don’t run into this issue.

  • Sorry for the very late answer, hopefully you got some info from other places of the internet, like stackoverflow or yapsy’s doc or support tickets, but here is a brief answer anyway:

    You’re pointing at a known caveat of yapsy’s current implementation, that will not change for a minor version. You can get more info on that + workarounds at

  • Grazfather x

    Thanks for getting back to me. We ended up implementing our own solution because of requirements specific to our project, but it’s nice to see that it was in the documentation — It looks like that work around would have been perfectly fine, but we would have eventually had to implement our own anyway.