On Wed, 2015-08-26 at 23:50 +0530, Chandra Shehkhar Reddy Potula wrote:Hi all,
Do we need to consider PEP 8 guidelines while naming the plugin ?
https://www.python.org/dev/peps/pep-0008/#package-and-module-namesPEP8 allows underscores. This could solve the problem I think. ginger_base, ginger_ppc, etc._______________________________________________
I see some issue by having "-" in the python plugin naming convention (ex: ginger-base), as import will not work directly.
Example: in the consider tests/test_host.py file, which contains statement
from kimchi.mockmodel import MockModel
when moved to ginger-base plugin become
from ginger-base.mockmodel import MockModel
python import will not recognize the module name with "-"
I could overcome that by :
import importlib mod = importlib.import_module("path.to.my-module") ormodule = __import__("path.to.my-module")
But I feel, It is not adhering PEP 8 guidelines.
So my proposal would be not to have "-" in the module name ? ie. gingerbase, gingerppc, gingers390x etc.. if so even api has to have the same convention ?
Any better suggestions are welcome.
Thanks and Regards
Chandra
On 08/12/2015 06:39 PM, Chandra Shehkhar Reddy Potula wrote:
Fine with me !!!
On 08/12/2015 06:13 PM, Daniel Henrique Barboza wrote:
On 08/12/2015 09:08 AM, Aline Manera wrote:
On 11/08/2015 13:27, Kevin Zander wrote:
On Tue, 2015-08-11 at 11:47 -0300, Aline Manera wrote:Hi all,
As we have agreed on moving the Kimchi Host tab to Ginger community and creating a new plugin (ginger-basic), I want to list step-by-step what we need to do *on Kimchi side*.
1) Will we call this new plugin as ginger-basic? Any other suggestion?
I think keeping it as ginger is better. ginger-basic sounds like there's ginger-advanced (or similar), when there really isn't anything like that. What we have is just additional functionality based on your OS flavor. So keeping ginger as the plugin name, to me, is the easiest. Then all it takes is looking up your flavor: ginger-[ppc|z|pickled].
About the plugin name: does ginger-base sound better? As it will the base for all the other ginger plugins which will extend the Host tab.
'ginger-base' looks OK to me
The other plug-in can be called simply 'ginger' in this case.
2) Create the new plugin structure into wok branch, ie, create a directory named ginger-basic (?) and all it is needed to launch it as a wok plugin, including building and packaging details.
In this first moment, the entire Host tab will be part of the ginger-basic - just to move the discussion as soon as possible to Ginger community.
3) Add ginger-basic plugin as a Kimchi dependency.
Once we have those items done, I will create a new repository for ginger-basic under kimchi-project organization in Github.
After that, the discussion *will be moved to Ginger community*, ie, all patches and discussion must be sent to the Ginger mailing list (https://lists.nongnu.org/mailman/listinfo/ginger-dev-list)
I have sent to Ginger community the next steps to be done there. Please, check: "[Ginger-dev-list] [RFC] Inheriting Kimchi's Host tab"
Let me know what you think about that.
Regards,
Aline Manera
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Kimchi-devel mailing list
Kimchi-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel