[pypy-dev] Re: [pypy-svn] rev 2674 - pypy/trunk/doc
holger krekel
hpk at trillke.net
Mon Dec 22 23:48:18 CET 2003
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
More information about the Pypy-dev
mailing list