Open Stack

I’d like to +1 the idea of moving these custom checks from repositories to hacking.

We, in murano, had a couple of commits, that added custom checks like checking that we do not use xrange, mutable objects as default arguments, etc. At first those look good and logical, but as their numbers grew, it started to look like it

1) bloats the repository with lot’s of unrelated, non-specific code/checks
2) makes OpenStack code-base less uniform (different project have different set of rules)
3) doesn’t reuse the same code, but encourages contributors to copy-paste the same rule to a dozen of repositories, which is a bad  thing overall

I believe that if you find yourself in a situation, where you want to add a custom check to repository — you should first consider adding this very check to hacking instead.

On the other hand releasing a new version of hacking and bumping it’s version in global requirements (it’s currently pinned to <0.11), might be a painful process. Is there any procedure, that hacking (and/or OS community as a whole) follows, regarding those upgrades?

-- 
Kirill Zaitsev
Murano team
Software Engineer
Mirantis, Inc

On 19 January 2016 at 16:38:56, Akihiro Motoki (amotoki at gmail.com) wrote:

2016-01-19 18:58 GMT+09:00 Kekane, Abhishek <Abhishek.Kekane at nttdata.com>:
>
>
> -----Original Message-----
> From: Andreas Jaeger [mailto:aj at suse.com]
> Sent: 19 January 2016 15:19
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all][clients] Enable hacking in python-*clients
>
> On 2016-01-19 10:44, Abhishek Kekane wrote:
>>> Hi Abishek,
>>
>>> In my understanding, hacking check is enabled for most (or all) of
>>
>>> python-*client.
>>
>>> For example, flake8 is run for each neutronclient review [1].
>>
>>> test-requirements installs hacking, so I believe hacking check is enabled.
>>
>>> openstackclient and novaclient do the same [2] [3].
>>
>>> Am I missing something?
>>
>> Hi Akhiro Motoki,
>>
>> Individual OpenStack projects has separate hacking module (e.g.
>> nova/hacking/checks.py) which contains additional rules other than
>> standard PEP8 errors/warnings.
>>
>> In similar mode can we do same in python-*clients?
>
> Let's share one common set of rules and not have each repo additional ones. So, if those are useful, propose them for the hacking repo.

Totally agree.

> To answer your questions: Sure, it can be done but why?
>
> Because we can encounter this issues in local environments only, also we can add custom checks like
> 1. use six.string_types instead of basestring
> 2. use dict.items or six.iteritems(dict) instead of dict.items
> 3. checks on assertions etc.

If you find hacking rules you feel useful for various projects,
I would suggest you try to add them to the hacking repo first.

If there is still a reasonable reasons to add the rules to individual repos,
you can propose them (though I believe it is a rare care).

I am not sure there are common rules specific to python-*client repos,
but it seems this is not a case of yours as far as I read this thread.

Akihiro


>
> Abhishek
>
> Andreas
> --
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ______________________________________________________________________
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
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/20160125/207ca2cc/attachment.html>