[openstack-dev] [Horizon] HACKING.rst and import standards
Tatiana V. Mazur
tmazur at mirantis.com
Thu Jun 6 08:44:17 UTC 2013
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
More information about the OpenStack-dev
mailing list