[openstack-dev] [all] Why do we have project specific hacking rules?
Ihar Hrachyshka
ihrachys at redhat.com
Wed Oct 5 15:28:15 UTC 2016
Ian Cordasco <sigmavirus24 at gmail.com> wrote:
> -----Original Message-----
> From: Tony Breeds <tony at bakeyournoodle.com>
> Reply: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>, OpenStack Development Mailing List
> (not for usage questions) <openstack-dev at lists.openstack.org>
> Date: October 5, 2016 at 08:14:40
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [all] Why do we have project specific
> hacking rules?
>
>> On Wed, Oct 05, 2016 at 07:56:15AM -0500, Ian Cordasco wrote:
>>
>>> So hacking doesn't push out to anyone. It's one of the projects that
>>> doesn't
>>> get updated by global-requirements updates, if I remember correctly.
>>
>> Just clarifying/confirming what Ian says.
>>
>> The proposal-bot does not generate updates to projects
>> *requirements.txt. It's
>> up to the projects to do that themselves.
>>
>> Having said that it *could* all the code is there but it was disabled
>> for a reason.
>
> Right. Thank you for clarifying, Tony.
>
> I believe several projects didn't want Hacking to auto-update and break
> things. With off-by-default rules (and the proliferation of them in
> Hacking) I don't think this is the most valid of concerns anymore. The
> only problem would be that pycodestyle and pyflakes frequently add new
> checks in releases means that the way Hacking pins Flake8 and
> itsdependencies is still necessary. We need to figure out how to keep
> up-to-date with our upstream dependencies without causing problems for
> projects. Until we do that, we should probably just keep our current
> methodology of letting projects update when they want to and can afford
> developer time to update.
I believe those transitive dependencies could be effectively pinned thru
upper-constraints.txt mechanism.
Ihar
More information about the OpenStack-dev
mailing list