[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