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

"Martin v. Löwis" martin at v.loewis.de
Wed Aug 5 10:09:47 CEST 2009

>> Now, the specific outcome of the process means that more work needs to
>> be done. So we have a *second* PEP, and we have a lack of volunteers
>> that help implementing it. The second PEP hasn't been approved yet
>> (as it isn't complete, yet), so migration to hg is stalled.
>> The primary volunteer (Dirkjan) has indicated that he can't help with
>> that specific issue, so other volunteers need to step forward, or we
>> cannot move to hg.
> I don't recall Dirkjan saying he can't help with that issue - was it a
> lack of time, or a lack of understanding the problem/lack of a Windows
> environment?

I think he said (at some point) that he is not a Windows user, and thus
can't really help. Of course, he also indicated that, as a Mercurial
contributor, he is willing to help as much as he can.

> The problem I see is a lack of agreement about exactly what the solution
> entails.  I believe there is general agreement win32text needs to be
> enhanced to support versioned 'rules'.  But even with that, the only
> option I see is a truly cross-platform extension to implement these
> rules which every Python committer, regardless of operating-system, is
> expected to use - but that doesn't seem the consensus.
> As mentioned, I'm willing to lend manpower for this once there is
> agreement on something workable...

I think it needs to work the other way 'round. Somebody (perhaps you)
needs to propose a hook and configuration settings, and propose that
this hook is used on every system, and that refusal to use these hooks
could lead to changes not being integratable (is that a word?).

There can't be consensus to use a solution that doesn't exist.

My personal favorite outcome would be this:
- most files have svn's "native" eol style; they get stored in LF
  in the repository; the hook will convert them on Windows, and check
  on Unix.
- some files have "windows" eol style; they get stored in CRLF.
  The hook will not convert, but only check.
- not sure whether some files need to be declared as "unix" eol style.
- some files are "binary"; they get stored as-is - the hook will
  do nothing.

With such a setup, using the hook would be truly optional on Unix,
as it only ever checks and never converts. So if you manage to mess
up, and don't have the hook installed on Unix, you lose when trying
to push. That will teach you to be more careful in the future, or
to install the hook (which hopefully becomes built into Mercurial at
some point).

Whether it is actually possible to implement all that, I don't know.


More information about the Python-Dev mailing list