[openstack-dev] [Horizon] HACKING.rst and import standards
Matt Joyce
matt.joyce at cloudscaling.com
Thu Jun 6 20:02:30 UTC 2013
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 <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
>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130606/cf786a18/attachment.html>
More information about the OpenStack-dev
mailing list