Open Stack

I suggest that we start with enabling H301 (one import per line), H303 (no wildcards), and H306 (alphabetical). I'm honestly surprised by how many violations there are for that last one since we generally try to do that already. Obviously it'll be a sizable patch to make this happen, but it'd be great to get it done. Please file a bug/blueprint for it.

Thanks!


-          Gabriel

From: Joe Gordon [mailto:joe.gordon0 at gmail.com]
Sent: Thursday, June 06, 2013 9:09 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Horizon] HACKING.rst and import standards

Although there is no HACKING.rst in Horizon, it does use the hacking plugin to flake8, just that the tests are all disabled.(https://github.com/openstack/horizon/blob/master/tox.ini#L40).  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.

'flake8 --statistics --select H3' shows the number off issues:

194     H301  one import per line
16      H302  import only modules.'from collections import Sequence' does not import a module
7       H303  No wildcard (*) import.
131     H304  No relative imports. 'from .views import UsageView' is a relative import
179     H306  imports not in alphabetical order (django.conf.urls.static.static, django.conf.settings)




On Thu, Jun 6, 2013 at 3:42 AM, Dolph Mathews <dolph.mathews at gmail.com<mailto:dolph.mathews at gmail.com>> wrote:
+1; that's why alphabetical imports and one import per line!


On Thursday, June 6, 2013, Bhandaru, Malini K wrote:
+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<mailto: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<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--

-Dolph

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130606/5e630afe/attachment-0001.html>