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

[Paul Moore]

2009/8/5 Mark Hammond <mhammond at skippinet.com.au>:
> Most tools that I use will tend to not mix EOL styles in a single file, but
> will tend to create \r\n line endings for new files I create.  Most hg repos
> I come across don't have mixed line endings within individual files, so I
> can only guess these files were accidentally introduced in the same way (and
> indeed I have personally done this.)  I'm hoping to be part of the solution
> instead of part of the problem :)

Interesting. I don't recall *ever* having generated CRLF line endings
in a LF-delimited file (I use Vim) although I may have created CRLF in
new files (and then not noticed, as Vim handles it transparently
enough that I missed it).

There are no significant projects where I'm a committer, though, so I
interact via patches, which means I don't get the opportunity to break
the repository :-)

> Technically it would be optional for everyone, of course.  However, the
> solution should be such that everyone, regardless of personal preference, is
> willing to take the hit.
>
> For example, if the repo is converted using \r\n line endings natively, then
> Windows users would need to take no action either and puts the onus back on
> you (given your stated preferences) to configure the tool appropriately.  I
> assume you would have no objection to that and would be happy to make that
> tool optional for me?

Absolutely. My issue is with 2 points:

1) I'm an infrequent contributor, so I don't keep a checkout around. I
make a new clone "on demand", so I would be likely to forget to enable
the hook on at least a proportion of my clones. The versioned .hgeols
proposal seems to cover this.

2) This behaviour is something needed for Python only. I've no issue
with enabling win32text globally, but I'd want to be clear that it is
a no-op unless specifically requested (ie, something like
**=cleverencode is *not* used in the absence of an explicit set of
rules). That may well be the case, but I had the impression that
win32text tried to be "automatic", so I'd like to verify it.

> I must concede that Windows developers are the minority here - but assuming
> we want a level playing field, I don't see how that changes the underlying
> issue...

Again, agreed entirely.

As a Windows developer who doesn't (knowingly) encounter the issue,
I'm not in a good position to help, but I'm happy to contribute
comments and test things. I'll be offline for a couple of weeks,
though, so you may well have solved it before I can do anything :-)

Paul