[openstack-dev] [Horizon] HACKING.rst and import standards
Akihiro MOTOKI
motoki at da.jp.nec.com
Fri Jun 7 07:05:06 UTC 2013
Strongly agreed.
> 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,
> )
A topic not discussed is module-level import vs object-level import.
While other core projects only use module-level import, Horizon uses both
and object-level imports are widely used like below.
I would like to use module-level import.
It reduces the number of imports and it has consistency with other project.
What do you think about it?
Thanks.
Akihiro
>>>>> Date: Thu, 6 Jun 2013 13:02:30 -0700
>>>>> From: Matt Joyce <matt.joyce at cloudscaling.com>
>>>>> Subject: Re: [openstack-dev] [Horizon] HACKING.rst and import standards
>> Huge +1
>> On Jun 6, 2013 12:03 PM, "Gabriel Hurley" <Gabriel.Hurley at nebula.com> wrote:
>> 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> 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
> 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
>> _______________________________________________
> OpenStack-dev mailing list
> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
> 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