Re: [Kimchi-devel] [RFC] The new ginger-basic plugin

Supporting Chandra, I think gingerbase, gingerppc, gingers390x should be okay even with readability point of view when compared with other existing python modules like ossaudiodev, sunaudiodev, gensuitemodule etc.. On 08/27/2015 04:20 PM, Chandra Shehkhar Reddy Potula wrote: > > On 08/27/2015 12:40 AM, Chandra Shehkhar Reddy Potula wrote: >> >> On 08/27/2015 12:33 AM, Paulo Ricardo Paz Vital wrote: >>> Supporting what Kevin mentioned, once PEP8 allows underscores, I >>> think that ginger_base, ginger_ppc, etc is better than name with no >>> division. >> I know that it improves readability, but on the other hand PEP8 >> guidelines discouraging usage of under score too in the module >> naming convention. >> Also think of how the REST API URI should look like. > > Also I went through some core python module developed and their > naming conventions. Most of them are with out underscore even though > they have multiple words in the name. > https://docs.python.org/2/py-modindex.html > > For example: findertools, > <https://docs.python.org/2/library/macostools.html#module-findertools>f..., > <https://docs.python.org/2/library/functools.html#module-functools>cont..., > <https://docs.python.org/2/library/contextlib.html#module-contextlib>co..., > distutils, ensurepip, findertools, > <https://docs.python.org/2/library/compileall.html#module-compileall>ft..., > <https://docs.python.org/2/library/ftplib.html#module-ftplib>gensuitemo..., > <https://docs.python.org/2/library/gensuitemodule.html#module-gensuitemodu... > <https://docs.python.org/2/library/htmllib.html#module-htmlentitydefs>;, > htplib, importlib, > <https://docs.python.org/2/library/gensuitemodule.html#module-gensuitemodu... > <https://docs.python.org/2/library/itertools.html#module-itertools>;, > ossaudiodev > <https://docs.python.org/2/library/ossaudiodev.html#module-ossaudiodev>;, > pickletools, rlcompleter, telentlib, unicodedata, zipimport etc... > <https://docs.python.org/2/library/rlcompleter.html#module-rlcompleter> > > Let me go ahead with gingerbase, gingerppc, gingers390x as plugin > names unless some one has serious objections. > > Will use the same name in the REST API uri as well. > > For example: > plugins/gingerbase/host > plugins/gingerbase/host/stats > > so on ... > I totally understand the readability part but I think going with out > "-" or "_" in the module name be the better choice. Let me know !!! > Regards Chandra >>> On Wed, Aug 26, 2015 at 3:38 PM Kevin Zander >>> <klzander(a)linux.vnet.ibm.com&gt; wrote: >>> >>> 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-names >>> >>> PEP8 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") >>>> >>>> or >>>> >>>> ||module= __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(a)ovirt.org <mailto:Kimchi-devel@ovirt.org> >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Kimchi-devel mailing list >>>>>>> Kimchi-devel(a)ovirt.org <mailto:Kimchi-devel@ovirt.org> >>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>>>>> >>>>>> _______________________________________________ >>>>>> Kimchi-devel mailing list >>>>>> Kimchi-devel(a)ovirt.org <mailto:Kimchi-devel@ovirt.org> >>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>>> _______________________________________________ >>>> Kimchi-devel mailing list >>>> Kimchi-devel(a)ovirt.org <mailto:Kimchi-devel@ovirt.org> >>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>> _______________________________________________ Kimchi-devel >>> mailing list Kimchi-devel(a)ovirt.org >>> <mailto:Kimchi-devel@ovirt.org> >>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>> >> _______________________________________________ >> Kimchi-devel mailing list >> Kimchi-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel