[Python-Dev] PEP 385: the eol-type issue
mhammond at skippinet.com.au
Wed Aug 5 01:43:15 CEST 2009
On 4/08/2009 7:20 PM, Nick Coghlan wrote:
> Dirkjan Ochtman wrote:
>>>> * commit hooks be implemented to enforce this - but this should not be
>>>> necessary if the above was implemented and socially enforced.
>> You seem to advocate a two-step approach: enforce line endings through
>> win32text, catch any errors that slipped through in a hook (commit
>> hook is an optional first line of defense, changegroup hooks on the
>> server to protect the rest of the world).
>> I think inverting that approach would be better: have strict hooks on
>> the server to prevent people from pushing inappropriate EOLs, and
>> provide help on configuring win32text as an extra help for developers
>> on Windows who use editors that work better with \r\n. That leaves
>> people to pick their own weapon of choice against propagation of \r\n
>> (e.g. better editor, commit hooks, whatever) while still making sure
>> no inappropriate line endings land in the python.org repositories. It
>> also seems to fit well with the whole consenting adults thing (but
>> that might just be me).
> It's about not treating Windows developers as second class citizens.
> Their platform uses \r\n as its native line ending format, so they
Thanks Nick; I didn't want to be the only one saying that. There is a
fine line between asserting reasonable requirements for Windows users
and being obstructionist and unhelpful, and I'm trying to stay on the
former side :)
> should be able to work in that format without any hassles by following
> some simple instructions (such as "ensure you have version X of the
> Windows hg client, enable the win32text extension and configure it in
> such-and-such a way"). Not "oh, yeah, that's an issue but if you search
> the Intarwebs there are a few different things you can do that kinda
> sorta work but are a bit fragile and klunky".
> The precise order the two issues (server side enforcement and client
> side assistance) are dealt with doesn't really matter because *both*
> issues need to be addressed before we migrate.
I'm not that happy with the server being the primary line of defense.
Let's say I make a branch of the hg repo, myself and a few others work
on it committing as we go, then attempt to merge back upstream. Let's
say some of the early commits on that clone introduced "bad" line
endings. I'm guessing I would be forced to make a number of
whitespace-only checkins to normalize the line-endings before it could
merge - and these checkins would then be in the history forever. Or I
could attempt to recreate the clone by somehow "replaying" the commits
with line endings corrected. Either way, the situation doesn't seem good.
> win32text needs to be usable on non-Windows clients so that tarballs
> generated on a *nix machine get the line endings right in the
> Windows-only files.
I agree. It isn't fair to make this windows users problem. It would be
like me proposing the repo get imported with \r\n line endings, enforce
that with server side hooks, and let non-Windows users worry about the
ramifications of that - somehow I doubt that would fly - so neither
should it fly for Windows users...
I'm more than willing to help on this; I haven't resurrected my stale
patch because I find win32text only 1/2 a solution that doesn't work in
practice. Therefore that patch is as stale for me as it is anyone.
However, if a plan is put in place which offers a full solution and the
hg developers are committed to it, I promise I'll put my hand up to help
with implementation in a fairly timely manner...
More information about the Python-Dev