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.
;,
pickletools, rlcompleter, telentlib, unicodedata, zipimport etc...
<
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> 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 :
>> |importimportlib 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