[RFC] The new ginger-basic plugin
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? 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
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
On Tue, 2015-08-11 at 11:47 -0300, Aline Manera wrote: 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].
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>
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]
The final goal of ginger-basic is to handle only host basic information, host statistics and debug reports. Those features were identified as common between Kimchi and Ginger so the need of a new plugin (ginger-basic). You can check the other thread where we decided to do that in: http://lists.ovirt.org/pipermail/kimchi-devel/2015-August/011173.html The idea of this email in only clarify what we need to do as we've already had an agreement in the concept. About the plugin name, you can suggest other one which may be better understood than ginger-basic - as you said it sounds to there is a ginger-advanced.
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 <mailto:Kimchi-devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 08/11/2015 02:17 PM, 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]
The final goal of ginger-basic is to handle only host basic information, host statistics and debug reports. Those features were identified as common between Kimchi and Ginger so the need of a new plugin (ginger-basic). You can check the other thread where we decided to do that in: http://lists.ovirt.org/pipermail/kimchi-devel/2015-August/011173.html
The idea of this email in only clarify what we need to do as we've already had an agreement in the concept.
About the plugin name, you can suggest other one which may be better understood than ginger-basic - as you said it sounds to there is a ginger-advanced.
'ginger-basic' is just a name. We can rename it to ginger-hostinfo, ginger-basicinfo and the plug-in that will add the current Ginger features can be named 'ginger-adm', 'ginger-advanced' .... We can discuss how each plug-in will be named (a discussion which belongs to ginger-dev-list@nongnu.org ) but, in my opinion, agreeing with the design is more important ATM.
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 <mailto: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
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.
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 <mailto:Kimchi-devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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 <mailto: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
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 <mailto: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
From an user perspective, ginger-base looks good! On Wed, 2015-08-12 at 18:39 +0530, 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:
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
On Tue, 2015-08-11 at 11:47 -0300, Aline Manera wrote: 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
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 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@ovirt.org <mailto: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
PEP8 says the following: https://www.python.org/dev/peps/pep-0008/#package-and-module-names " Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged." So I believe you're right - we can't have the minus sign in the middle of the plug-in names. I am fine with your solution of simply getting rid of the "-" and name them gingerbase, gingerppc, gingerz and so on. Daniel On 08/26/2015 03:20 PM, 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
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@ovirt.org <mailto: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
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@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>
Supporting what Kevin mentioned, once PEP8 allows underscores, I think that ginger_base, ginger_ppc, etc is better than name with no division. On Wed, Aug 26, 2015 at 3:38 PM Kevin Zander <klzander@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 :
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 listKimchi-devel@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing listKimchi-devel@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing listKimchi-devel@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing listKimchi-devel@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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.
On Wed, Aug 26, 2015 at 3:38 PM Kevin Zander <klzander@linux.vnet.ibm.com <mailto:klzander@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@ovirt.org <mailto:Kimchi-devel@ovirt.org> > http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org <mailto:Kimchi-devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org <mailto:Kimchi-devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org <mailto:Kimchi-devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org <mailto:Kimchi-devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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>functools, <https://docs.python.org/2/library/functools.html#module-functools>contextlib, <https://docs.python.org/2/library/contextlib.html#module-contextlib>compileall, distutils, ensurepip, findertools, <https://docs.python.org/2/library/compileall.html#module-compileall>ftplib, <https://docs.python.org/2/library/ftplib.html#module-ftplib>gensuitemodule, <https://docs.python.org/2/library/gensuitemodule.html#module-gensuitemodule><https://docs.python.org/2/library/gensuitemodule.html#module-gensuitemodule>htmlentitydefs <https://docs.python.org/2/library/htmllib.html#module-htmlentitydefs>, htplib, importlib, <https://docs.python.org/2/library/gensuitemodule.html#module-gensuitemodule>itertools <https://docs.python.org/2/library/itertools.html#module-itertools>, <https://docs.python.org/2/library/pickletools.html#module-pickletools>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@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@ovirt.org <mailto:Kimchi-devel@ovirt.org> >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org <mailto:Kimchi-devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org <mailto:Kimchi-devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org <mailto:Kimchi-devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org <mailto: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
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>functools, <https://docs.python.org/2/library/functools.html#module-functools>contextlib, <https://docs.python.org/2/library/contextlib.html#module-contextlib>compileall, distutils, ensurepip, findertools, <https://docs.python.org/2/library/compileall.html#module-compileall>ftplib, <https://docs.python.org/2/library/ftplib.html#module-ftplib>gensuitemodule, <https://docs.python.org/2/library/gensuitemodule.html#module-gensuitemodule><https://docs.python.org/2/library/gensuitemodule.html#module-gensuitemodule>htmlentitydefs <https://docs.python.org/2/library/htmllib.html#module-htmlentitydefs>, htplib, importlib, <https://docs.python.org/2/library/gensuitemodule.html#module-gensuitemodule>itertools <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@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@ovirt.org <mailto:Kimchi-devel@ovirt.org> >>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel@ovirt.org <mailto:Kimchi-devel@ovirt.org> > http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org <mailto:Kimchi-devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org <mailto:Kimchi-devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org <mailto: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
+1 for gingerbase, gingerppc, etc... On 27/08/2015 08:58, Suresh Babu Angadi wrote:
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>functools, <https://docs.python.org/2/library/functools.html#module-functools>contextlib, <https://docs.python.org/2/library/contextlib.html#module-contextlib>compileall, distutils, ensurepip, findertools, <https://docs.python.org/2/library/compileall.html#module-compileall>ftplib, <https://docs.python.org/2/library/ftplib.html#module-ftplib>gensuitemodule, <https://docs.python.org/2/library/gensuitemodule.html#module-gensuitemodule><https://docs.python.org/2/library/gensuitemodule.html#module-gensuitemodule>htmlentitydefs <https://docs.python.org/2/library/htmllib.html#module-htmlentitydefs>, htplib, importlib, <https://docs.python.org/2/library/gensuitemodule.html#module-gensuitemodule>itertools <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@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 : |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@ovirt.org <mailto:Kimchi-devel@ovirt.org> >>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >> >> _______________________________________________ >> Kimchi-devel mailing list >> Kimchi-devel@ovirt.org <mailto:Kimchi-devel@ovirt.org> >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel@ovirt.org <mailto:Kimchi-devel@ovirt.org> > http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org <mailto:Kimchi-devel@ovirt.org> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org <mailto: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
Agreed. I will be working on this topic. On 08/12/2015 11:27 AM, Harshal Patil wrote:
SGTM.
----- Original message ----- From: Aline Manera <alinefm@linux.vnet.ibm.com> Sent by: kimchi-devel-bounces@ovirt.org To: Kimchi Devel <kimchi-devel@ovirt.org> Cc: Subject: [Kimchi-devel] [RFC] The new ginger-basic plugin Date: Tue, Aug 11, 2015 8:20 PM
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?
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
I agree. On 12.08.2015 08:25, Chandra Shehkhar Reddy Potula wrote:
Agreed. I will be working on this topic.
On 08/12/2015 11:27 AM, Harshal Patil wrote:
SGTM.
----- Original message ----- From: Aline Manera <alinefm@linux.vnet.ibm.com> Sent by: kimchi-devel-bounces@ovirt.org To: Kimchi Devel <kimchi-devel@ovirt.org> Cc: Subject: [Kimchi-devel] [RFC] The new ginger-basic plugin Date: Tue, Aug 11, 2015 8:20 PM
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?
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
participants (9)
-
Aline Manera -
Chandra Shehkhar Reddy Potula -
Daniel Henrique Barboza -
Daniel Henrique Barboza -
Harshal Patil -
Kevin Zander -
Paulo Ricardo Paz Vital -
Suresh Babu Angadi -
Walter Niklaus