[Python-Dev] PEP 385: the eol-type issue

[Dirkjan Ochtman]

So, I've been not-working on this, which I feel bad about. Suffice it
to say the day job has required more of my time then usual for the
past few weeks. I want to get back into it, so let's start by
re-raising this issue, which Mark Hammond conveniently summarized
below.

> On 4/07/2009 2:03 PM, Mark Hammond wrote:
>> On 4/07/2009 12:30 PM, Nick Coghlan wrote:
>>> And since Mercurial doesn't even allow us to say "this is a binary file"
>>> the way CVS used to I'm currently not seeing any way for that to happen
>>> except for win32text to be updated to correctly handle wild cards in
>>> combination with negative filters.
>>
>> I agree with your conclusion. My ruminating on this over the last few
>> months leaves me thinking this would involve:
>>
>> * my older 'accepted but then lost' hg patch to allow an explicit 'none'
>> rule for a single file to override wildcards.

This was and still is a good idea. It would be very nice if you could
un-bitrot it and submit it for inclusion into crew-stable (so that it
may land in the next release, which would hopefully be a somewhat near
1.3.2).

>> * win32text be enhanced to use a normal versioned file in the root of
>> the repo, much like hgingore, where a project can maintain project wide
>> rules.

I'm thinking that it should take stuff from .hgeols or whatever and
apply rules from .hg/hgrc after that, so both may be used (and for
backwards compatibility), but it sounds like a good idea in principle.

>> * win32text be enhanced such that all python developers, regardless of
>> platform, are willing to use this extension, even if the majority of
>> files happen to use their native line ending (sauce for the goose is
>> sauce for the gander, and all that...)

I don't think that is necessary, I will elaborate below.

>> * 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).

On Sun, Jul 19, 2009 at 15:27, Mark Hammond<skippy.hammond at gmail.com> wrote:
> Sorry Dirkjan - I just noticed I didn't CC you on this mail originally.  I'm
> wondering if you have any more thoughts on these EOL issues and if there is
> anything I can do to help?

Taking up the 'none' filter, first, and .hgeols, secondly, in the
win32text extension would be wonderfully helpful, since I don't do
much development on Windows and am therefore not that familiar with
the extension in the first place.

Cheers,

Dirkjan