Open Stack

On 10/29/13 at 10:53am, Joe Gordon wrote:
>So after over 20 messages in this thread, now what?
>
>From my count we have 3 -, and 12 +1s.  Is that enough for consensus? Do we
>move modelines lines to the bottom?  Put them in every file? Or just remove
>them?

I have no strong feeling either way on keeping or removing them.  But if 
they're going to be removed from individual files it may be helpful to 
add one in the HACKING.rst text.  Not as a modeline but as guidance on 
configuring vim.  And examples could be added for other editors if 
that's desired.


>
>https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:noboilerplate,n,z
>https://review.openstack.org/#/c/51295/
>
>
>On Mon, Oct 28, 2013 at 10:54 AM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>
>>
>>
>>
>> On Mon, Oct 28, 2013 at 9:35 AM, Alexis Lee <alexisl at hp.com> wrote:
>>
>>> As a new OpenStack contributor, +1 for lower barriers to entry. It's
>>> helpful for OS to inform editor style and I don't believe in the
>>> arguments to remove them.
>>>
>>> > Why remove them?
>>> > * we could shrink our codebase by a little bit.
>>>
>>> Why do you want to shrink it? Simplify, sure, but modelines are not
>>> code (not Python anyway). Even so, it's only one line per file.
>>>
>>> > * Modelines aren't supported by default in debian or ubuntu due to
>>> > security reasons: https://wiki.python.org/moin/Vim
>>>
>>> As I believe with many Vim users, my .vimrc greatly predates my
>>> involvement with OpenStack and it reflects my personal preferences (like
>>> Termie's). I really wouldn't rely on the defaults surviving initial user
>>> contact.
>>>
>>> > * Having modelines for vim means if someone wants we should support
>>> > modelines for emacs
>>> > (
>>> http://www.gnu.org/software/emacs/manual/html_mono/emacs.html#Specifying-File-Variables
>>> )
>>>
>>> I don't see a problem supporting Emacs, as the other major UNIX editor.
>>> The slippery slope runs dry very quickly after that, I don't see gedit
>>> users petitioning for inclusion (no offense intended to any gedit
>>> devotees!).
>>>
>>> Alternatively Emacs users as self-proclaimed users of the bestest editor
>>> ever could just install: https://github.com/cinsk/emacs-vim-modeline
>>> and brag about how flexible their editor is.
>>
>>
>>> > * There are other ways of making sure tabstop is set correctly for
>>> > python files, see  https://wiki.python.org/moin/Vim.  I am a vIm user
>>> > myself and have never used modelines.
>>>
>>> I am a Vim user and frequently use modelines! I like that they 'stick'
>>> to files so even if a file gets separated from its project, the modeline
>>> remains.
>>>
>>
>> From an OpenStack point of view, that is not an issue.  If a file gets
>> separated then why should we worry about if it has a pep8 friendly tabstop?
>>
>>
>>>
>>> If I wanted to work on a project with style contrary to OpenStack's, I'd
>>> need to write project-specific autocommands. It feels right to me that
>>> if a project requires specific style, it should gate it (as OS does) and
>>> provide some informative help as well (the modelines).
>>>
>>
>> We don't just gate without telling people, the first two items in hacking
>> are read pep8
>>
>> http://docs.openstack.org/developer/hacking/
>>
>>
>>>
>>> OS could provide a vim script to set up project-specific style but this
>>> fails the barrier-to-entry test.
>>>
>>> > * We have vim modelines in only 828 out of 1213 python files in nova
>>> > (68%), so if anyone is using modelines today, then it only works 68% of
>>> > the time in nova
>>>
>>> Then we should fix that, in accordance with OS style guidelines.
>>> It's also possible those are the high-touch files?
>>>
>>
>> As of writing this email we don't OS style guidelines (hacking) don't
>> require vim modelines.  This thread is trying to resolve this.
>>
>>
>>>
>>> > * Why have the same config 828 times for one repo alone?  This
>>> > violates the DRY principle (Don't Repeat Yourself).
>>>
>>> Because afaik there's no standard way to inform editors of
>>> project-specific style guidelines. Plus previously mentioned benefit of
>>> stickiness.
>>>
>>
>> PEP8 is hardly project specific.
>>
>>
>>
>>>
>>>
>>> John Dennis said on Fri, Oct 25, 2013 at 04:12:35PM -0400:
>>> > Emacs... requires the per file variables to be the 1st line . So don't
>>> > see how vim and emacs specifications will coexist nicely and stay that
>>> > way consistently.
>>>
>>> What's the problem? Vim has no such limitation, Emacs can have 1st line
>>> + Vim 2nd.
>>>
>>> > My personal feeling is you need to have enough awareness to configure
>>> > your editor correctly to contribute to a project. It's your
>>> > responsibility and our gate tools will hold you to that promise.
>>>
>>> That's not very welcoming. If a project want to be particular about
>>> its style, it has a responsibilty to not just gate but also assist in
>>> following that style.
>>>
>>
>> We do try to make it easy to follow the style. Its fully documented here
>> http://docs.openstack.org/developer/hacking/.  Also the modeline we use
>> is hardly enough to follow the style (80 char limit, spacing between
>> functions, between classes etc.) And we provide several ways for a user to
>> run the full set of style tests locally.
>>
>> * Install hacking locally (pip install hacking), and run 'flake8' - which
>> has a really nice vim plugin too  (https://github.com/nvie/vim-flake8)
>> * Just run 'tox -epep8'
>>
>>
>>
>>> I should mention that not long ago I spent a good half day reading
>>> OpenStack materials on "this is how things must be done", too long imho.
>>>
>>> > Let's just remove the mode lines, they really don't belong in every
>>> file.
>>>
>>> Let's just leave them. It's a big change, some people like them and the
>>> benefits of removal are minimal at best.
>>>
>>>
>>> Alexis
>>> --
>>> Nova Engineer, HP Cloud.  AKA lealexis, lxsli.
>>>
>>> _______________________________________________
>>> 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