[openstack-dev] [Horizon] HACKING.rst and import standards
Bhandaru, Malini K
malini.k.bhandaru at intel.com
Thu Jun 6 09:17:44 UTC 2013
+1
Anything to avoid/ease manual merge. Good job describing problem Tatiana.
Malini
-----Original Message-----
From: Tatiana V. Mazur [mailto:tmazur at mirantis.com]
Sent: Thursday, June 06, 2013 1:44 AM
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] [Horizon] HACKING.rst and import standards
Hello!
Recently I had to upload some patch sets and rebase some branches for this purpose. It appears that rebasing on changed master branch is not a trivial task. You know, when nearly each Horizon module includes a total mash of comma separated imports, that's really not a trivial task.
Problems start when you add some method from the same module in an existing import statement like here:
from .views import (IndexView, CreateView, EditAttachmentsView, DetailView,
CreateSnapshotView)
or even here:
from .views import IndexView
from .views import AddPoolView, AddMemberView, AddMonitorView, AddVipView from .views import (UpdatePoolView, UpdateMemberView,
UpdateVipView, UpdateMonitorView) from .views import PoolDetailsView, VipDetailsView from .views import MemberDetailsView, MonitorDetailsView from .views import AddPMAssociationView, DeletePMAssociationView
All patch sets including this kind of changes can't be merged automatically. You have to rebase manually, just because of a few imports. I was wondering if there is a local Horizon standard for importing and tried to find it in HACKING.rst (like all standards are described in other projects). And it appears there's no HACKING.rst in Horizon! That's why I have a few questions:
1. Does it make sense to implement all imports uniformly like that is done in other projects?
Something like this would be nice:
from quantum.api.extensions import (
ExtensionMiddleware,
PluginAwareExtensionManager,
)
from quantum.common import config
from quantum.extensions import (
credential,
qos,
)
Or just one import per line. That would solve merging problems and code would look much better.
2. Does it make sense to add HACKING.rst in Horizon?
I think yes. We could describe standards there and we would never get such kind of rebase and merge problems.
What do you think about it? I could do it if you find it reasonable .
Kind regards,
Tatiana
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list