<div dir="ltr">Although there is no HACKING.rst in Horizon, it does use the hacking plugin to flake8, just that the tests are all disabled.(<a href="https://github.com/openstack/horizon/blob/master/tox.ini#L40">https://github.com/openstack/horizon/blob/master/tox.ini#L40</a>). You can start gating on one import per line (H301) and alphabetical order (H306), by fixing the issues and re-enabling the checks in tox.ini.<div>
<br></div><div>'flake8 --statistics --select H3' shows the number off issues:</div><div><br></div><div><div>194 H301 one import per line</div><div>16 H302 import only modules.'from collections import Sequence' does not import a module</div>
<div>7 H303 No wildcard (*) import.</div><div>131 H304 No relative imports. 'from .views import UsageView' is a relative import</div><div>179 H306 imports not in alphabetical order (django.conf.urls.static.static, django.conf.settings)</div>
</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 6, 2013 at 3:42 AM, Dolph Mathews <span dir="ltr"><<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1; that's why alphabetical imports and one import per line!<div class="HOEnZb"><div class="h5"><span></span><br><br>
On Thursday, June 6, 2013, Bhandaru, Malini K wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+1<br>
<br>
Anything to avoid/ease manual merge. Good job describing problem Tatiana.<br>
Malini<br>
<br>
-----Original Message-----<br>
From: Tatiana V. Mazur [mailto:<a>tmazur@mirantis.com</a>]<br>
Sent: Thursday, June 06, 2013 1:44 AM<br>
To: <a>openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [Horizon] HACKING.rst and import standards<br>
<br>
Hello!<br>
<br>
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.<br>
Problems start when you add some method from the same module in an existing import statement like here:<br>
<br>
from .views import (IndexView, CreateView, EditAttachmentsView, DetailView,<br>
CreateSnapshotView)<br>
<br>
or even here:<br>
<br>
from .views import IndexView<br>
from .views import AddPoolView, AddMemberView, AddMonitorView, AddVipView from .views import (UpdatePoolView, UpdateMemberView,<br>
UpdateVipView, UpdateMonitorView) from .views import PoolDetailsView, VipDetailsView from .views import MemberDetailsView, MonitorDetailsView from .views import AddPMAssociationView, DeletePMAssociationView<br>
<br>
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:<br>
<br>
1. Does it make sense to implement all imports uniformly like that is done in other projects?<br>
<br>
Something like this would be nice:<br>
<br>
from quantum.api.extensions import (<br>
ExtensionMiddleware,<br>
PluginAwareExtensionManager,<br>
)<br>
from quantum.common import config<br>
from quantum.extensions import (<br>
credential,<br>
qos,<br>
)<br>
<br>
Or just one import per line. That would solve merging problems and code would look much better.<br>
<br>
2. Does it make sense to add HACKING.rst in Horizon?<br>
<br>
I think yes. We could describe standards there and we would never get such kind of rebase and merge problems.<br>
<br>
What do you think about it? I could do it if you find it reasonable .<br>
<br>
<br>
Kind regards,<br>
Tatiana<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a>OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a>OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote><br><br></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><br></div>-Dolph<br>
</font></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>