OS Neutrality in Python Development Guidelines?

[Chris Johns]

On 20/4/21 4:12 am, Sebastian Huber wrote:
> On 19/04/2021 18:48, Gedare Bloom wrote:
> 
>>>> A random pick of a file and a brief scan ...
>>>>
>>>> https://git.rtems.org/rtems-central/tree/rtemsspec/interface.py#n313
>>> There is no issue in this line.

I disagree. At a technical level there is an issue. Python provides os.linesep
to handle this specific case. Any place you force the ending the has to be
considered code brittle. Maybe the code will not show any issue but what it
creates may.

>> I believe some can configure their git to inject \n\r on clone/pull
>> and fixes it up on commit. I have to do this for example to use
>> Windows source files in some projects where the IDE is only available
>> there.
> 
> This code generates C source files for RTEMS. These files should have Unix line
> endings.

A more specific and maybe better version of this sentence is ...

  "This code generates C source files for RTEMS on the host the
   generator is run on. The files have host's end of line
   encoding."

> There are probably Git users on Windows which enable the LF to CRLF conversion.
> There are probably also Git users on Windows which don't enable this feature.

This should be covered by the format we hold for the files in the repo and what
the user has or uses is for them to manage. If a tool such as a git defaults to
the host standard and our tools also use that same default then things should work.

My experience over the last decade of the RSB has taught me if it is wrong it
will show up. A guide needs to cover these issues and we need to review so our
code meets those guide lines.

Chris