On Monday 22 December 2003 06:07 pm, holger krekel wrote: ...

...

...

several times i think it makes sense to think of some convention which allows the diffs to stay readable.

Maybe (especially) ReST-changes should be done with a two-step approach: first the one where you can read the content diff and then the one (if neccessary at all) which has purely formatting changes and says so in the commit message. And we might also think about a common line width so that not everybody reformats the text again and again :-)

Yes, good points. I think line length of <80, indents of 4 spaces, no tabs, no traling spaces allowed on any line under any pretext whatsoever, would be good conventions; I find it extremely hard to edit files (be they sources, ReST, or any other text) that fail to meet these conventions.

For python source files this is fine for me. I am not entirely sure for ReST especially since you can have verbatim-blocks (say an excerpt from a mail).

In this case, the checker should be more smart -- know something about ReST syntax, if it's crucial to allow "verbatim blocks" to break what would otherwise be the conventions (particularly if we enforce them, see below).

...

Is there a way, with subversion, to have a simple conformance test for this kind of formatting parameters be run automatically, whenever a textfile is committed? If files breaking these conventions (or whatever conventions we can all agree on) were never committed, this would minimize the need for "changes that are purely related to formatting", I think.

Indeed. A pre-commit hook is able to perform checks like this although the details might get hairy if you go for "indentation of four-spaces" enforcement (e.g. considering docstrings) . I guess i'd go for simplicity

I would agree, as I don't see the need for "verbatim blocks" in our docs, but you're the one who brought the subject up so I guess you must have something in mind about them? As for Python's docstrings, again the checker should be a bit more smart (use Python's tokenizer to check indent lengths but not within multistring literals). But as a first pass we can surely "not enforce this yet" (it will only mean a few more "formatting only" changes needed).

and just enforce "line-length < 80" and svn:eol-style==native for all *.py

...and no tabs and no trailing spaces on lines...? Doesn't seem any more complicated than line length and eol-style (or am I missing something?).

and *.txt files (unless their svn:mime-type is explicitely non-text or some such). Non-conforming commits would simply be refused and nothing would be changed on the fly. Opinions?

Full agreement on refusing nonconforming commits (ideally with a clear message). One issue is that the existing files are sure to contain a lot of violations. If we start enforcing the rules, then perhaps to commit a tiny change somewhere in a file with a lot of violations one would have also to undertake a massive reformatting-only exercise. Perhaps we could enforce the rules only when the file is new OR the existing file (i.e. the version before the commit) respects the rules...? Alex

Hi Bengt, [Bengt Richter Mon, Dec 22, 2003 at 01:17:03PM -0800]

At 18:07 2003-12-22 +0100, you (holger krekel) wrote:

...

Hi Alex,

[Alex Martelli Mon, Dec 22, 2003 at 05:52:40PM +0100]

...

Is there a way, with subversion, to have a simple conformance test for this kind of formatting parameters be run automatically, whenever a textfile is committed? If files breaking these conventions (or whatever conventions we can all agree on) were never committed, this would minimize the need for "changes that are purely related to formatting", I think.

Indeed. A pre-commit hook is able to perform checks like this although the details might get hairy if you go for "indentation of four-spaces" enforcement (e.g. considering docstrings) . I guess i'd go for simplicity and just enforce "line-length < 80" and svn:eol-style==native for all *.py and *.txt files (unless their svn:mime-type is explicitely non-text or some such). Non-conforming commits would simply be refused and nothing would be changed on the fly. Opinions?

Comments from left field (since I wound up a mere lurker after all ;-)

Your are welcome and that can change, anyway :-)

1. I could see automated refusal of commits being a nuisance unless there was an override available.

If we choose transparent and consensual rules and can provide nice error messages i think they should help more then do harm. Often have people checked in files just to find out they did wrong and had to checkin another time ...

2. What about a separate pypytidy.py tool that people could use like a standards-enforcer/beautifier/spell-checker _before_ committing? Seems like an enforcer-hook would contain much of the logic anyway, and done separately a useful tool could evolve as a side effect.

we have pypy/tool/fixeol.py although this mainly deals with line endings. Our tools sections is an ever expanding branch of PyPy :-) cheers, holger

On Monday 22 December 2003 06:07 pm, holger krekel wrote: ...

...

...

several times i think it makes sense to think of some convention which allows the diffs to stay readable.

Maybe (especially) ReST-changes should be done with a two-step approach: first the one where you can read the content diff and then the one (if neccessary at all) which has purely formatting changes and says so in the commit message. And we might also think about a common line width so that not everybody reformats the text again and again :-)

Yes, good points. I think line length of <80, indents of 4 spaces, no tabs, no traling spaces allowed on any line under any pretext whatsoever, would be good conventions; I find it extremely hard to edit files (be they sources, ReST, or any other text) that fail to meet these conventions.

For python source files this is fine for me. I am not entirely sure for ReST especially since you can have verbatim-blocks (say an excerpt from a mail).

In this case, the checker should be more smart -- know something about ReST syntax, if it's crucial to allow "verbatim blocks" to break what would otherwise be the conventions (particularly if we enforce them, see below).

...

Is there a way, with subversion, to have a simple conformance test for this kind of formatting parameters be run automatically, whenever a textfile is committed? If files breaking these conventions (or whatever conventions we can all agree on) were never committed, this would minimize the need for "changes that are purely related to formatting", I think.

Indeed. A pre-commit hook is able to perform checks like this although the details might get hairy if you go for "indentation of four-spaces" enforcement (e.g. considering docstrings) . I guess i'd go for simplicity

I would agree, as I don't see the need for "verbatim blocks" in our docs, but you're the one who brought the subject up so I guess you must have something in mind about them? As for Python's docstrings, again the checker should be a bit more smart (use Python's tokenizer to check indent lengths but not within multistring literals). But as a first pass we can surely "not enforce this yet" (it will only mean a few more "formatting only" changes needed).

and just enforce "line-length < 80" and svn:eol-style==native for all *.py

...and no tabs and no trailing spaces on lines...? Doesn't seem any more complicated than line length and eol-style (or am I missing something?).

and *.txt files (unless their svn:mime-type is explicitely non-text or some such). Non-conforming commits would simply be refused and nothing would be changed on the fly. Opinions?

Full agreement on refusing nonconforming commits (ideally with a clear message). One issue is that the existing files are sure to contain a lot of violations. If we start enforcing the rules, then perhaps to commit a tiny change somewhere in a file with a lot of violations one would have also to undertake a massive reformatting-only exercise. Perhaps we could enforce the rules only when the file is new OR the existing file (i.e. the version before the commit) respects the rules...? Alex

Hi Bengt, [Bengt Richter Mon, Dec 22, 2003 at 01:17:03PM -0800]

At 18:07 2003-12-22 +0100, you (holger krekel) wrote:

...

Hi Alex,

[Alex Martelli Mon, Dec 22, 2003 at 05:52:40PM +0100]

...

Is there a way, with subversion, to have a simple conformance test for this kind of formatting parameters be run automatically, whenever a textfile is committed? If files breaking these conventions (or whatever conventions we can all agree on) were never committed, this would minimize the need for "changes that are purely related to formatting", I think.

Indeed. A pre-commit hook is able to perform checks like this although the details might get hairy if you go for "indentation of four-spaces" enforcement (e.g. considering docstrings) . I guess i'd go for simplicity and just enforce "line-length < 80" and svn:eol-style==native for all *.py and *.txt files (unless their svn:mime-type is explicitely non-text or some such). Non-conforming commits would simply be refused and nothing would be changed on the fly. Opinions?

Comments from left field (since I wound up a mere lurker after all ;-)

Your are welcome and that can change, anyway :-)

1. I could see automated refusal of commits being a nuisance unless there was an override available.

If we choose transparent and consensual rules and can provide nice error messages i think they should help more then do harm. Often have people checked in files just to find out they did wrong and had to checkin another time ...

2. What about a separate pypytidy.py tool that people could use like a standards-enforcer/beautifier/spell-checker _before_ committing? Seems like an enforcer-hook would contain much of the logic anyway, and done separately a useful tool could evolve as a side effect.

we have pypy/tool/fixeol.py although this mainly deals with line endings. Our tools sections is an ever expanding branch of PyPy :-) cheers, holger