[Python-Dev] PEP 385: the eol-type issue
Nick Coghlan
ncoghlan at gmail.com
Tue Aug 4 11:20:13 CEST 2009
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
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.
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.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
More information about the Python-Dev
mailing list