DVCS Ponies
So, I have a pony to share. Just maybe someone likes the idea and has thought of something similar :) So, one of the problems the Python guys currently have with mercurial is, that they need newline normalization/conversion on checkout. The problem with decentralized systems is that the client is a server and runs a stock DVCS client with his own set of hooks. In subversion you have a centralized hook that will check stuff and reject commits or rewrite them if they do not work out as expected.
Now I am very happy that hg is decentralized, but at the end of the day everything ends up in a centralized repository and there certain rules apply. So what I do is review all patches by hand in detail and rewrite parts if they do not match the code style, line endings etc. So what I thought about is doing the check/conversion in a local commit hook and in a pre-changeset hook on the server as well, so that I for myself get stopped early checking stupid stuff in and the server later rejects changesets for sure that are improper.
So I have no problem doing that check twice, but other users that are not so fortunate to have my extension might still check improper stuff in and will not even know it, because nothing stops them from doing so. But I will still have to deal with that later and there will be rejections from the server.
So what about an optional extension distribution system? Say you clone the zine repository and the hg client after clone proposes to download and activate some extensions for you? You can still veto them of course, but you could also accept and it helps to improve your code quality.
There are a couple of such extensions I would love to see that are distributed that way:
- codestyle (PEP 8) conformance checker that warn if invalid stuff is checked in
- newline conversions or warnings
- ensures that files end with a trailing newline
- warnings if certain files are checked in (object files, debugger informations etc, stackdumps etc.)
- automatic copyright header updating tools (got a change in 2010? Copyright message is updated)
- check line lengths
- run test suites
All these extensions are project specific so someone has to adapt them for each project and provide them somewhere to download. There could be a .hgextensions file that contains download links for each of those extensions (including mirrors) or even relative links to extension scripts in the repository.
I think that would be easy to implement and if the user has the chance to veto the installation/activation it could be quite secure as well (one could even display the user the code of the extension he is about to install for that repository). Unfortunately it would require a change in the hg wire protocol so I guess it's unlikely to be implemented, but on the other hand if there is a wire protocol change planned, why not think about that?
Interested to hear your input :)
If this was Facebook I could just click "Like" :)
— David Cramer on Sunday, January 10, 2010 0:45 #
Not sure it would need a protocol change. If it was just a magic file checked in to the repo that triggered it you could probably make a meta-extension that implemented it I would think. Just look on update if that file is changing and re-parse it. Download/link the correct files and edit the local config file.
— Noah Kantrowitz on Sunday, January 10, 2010 8:09 #
Is there already a codestyle conformance checker for PEP 8?
— René Leonhardt on Sunday, January 10, 2010 11:40 #
What Noah said. Implementing this as an extension (so you enable that, then everything get enabled as needed), might be a great idea.
— Dirkjan Ochtman on Sunday, January 10, 2010 12:05 #
@2: I guess, but people that would install a metaextension would also install the extension :)
— Armin Ronacher on Sunday, January 10, 2010 13:15 #
René: pypi.python.org/pypi/pep8/ is pretty handy and would make a great pre-commit check, especially in conjunction with something like pyflakes.
I'd go a step further, however, and suggest that a really powerful addition would be creating the Python equivalent of gofmt (golang.org/cmd/gofmt/) which could avoid some of the common minor warnings (i.e. using two spaces before a class & other whitespace changes) which makes people miss the more important stuff in PEP-8 and also provides a lot of noise when reviewing commits.
— Chris Adams on Sunday, January 10, 2010 14:58 #
Its an excellent post. Really enjoyed reading it. Good luck.
— Sorav Jain on Sunday, January 10, 2010 19:57 #
@6: The problem with tools like pep8, pyflakes, and pylint is that they are often very wrong (i.e. they'll give error for things that are not errors at all). I once tried to disable wrong messages in pylint one at a time as I found them. Soon I found that I've disabled almost all the messages... which makes it pretty much useless.
CPython already comes with a tool similar to gofmt, but does very little compared to gofmt. It only formats indentation and whitespace: svn.python.org/projects/python/trunk/Tools/scripts/reindent.py
I wrote a hg extension around reindent.py and gofmt a while ago: bitbucket.org/fhs/hgstyle/
— Fazlul Shahriar on Monday, January 11, 2010 4:28 #
Like it :)
— DasIch on Wednesday, January 13, 2010 17:59 #
Awesome idea.
I'll love to have some sort of meta extension that will add those hooks automagically based on a configuration.
— Jorge Vargas on Thursday, January 21, 2010 11:03 #
Great work and ideas, thanks.
— karen on Thursday, March 4, 2010 18:16 #