Configurable line endings when serializing about configparser-rs

[QEDK]

Hello,

Currently, when serializing, configparser-rs always uses unix line endings ('\n', lf). On the python side, configparser will use the appropriate line ending depending on the platform it's currently running on (crlf on windows, lf everywhere else).

I think it'd be nice if configparser would allow configuring the line endings being used, e.g. add an enum to IniDefaults to let the user chose between Lf and Crlf line endings.

Good point, I will look into this a bit more and make a decision.

[QEDK]

Hello,

Currently, when serializing, configparser-rs always uses unix line endings ('\n', lf). On the python side, configparser will use the appropriate line ending depending on the platform it's currently running on (crlf on windows, lf everywhere else).

I think it'd be nice if configparser would allow configuring the line endings being used, e.g. add an enum to IniDefaults to let the user chose between Lf and Crlf line endings.

Thought about this a bit more and I'm honestly not sure how useful this would be. Rust does not support optional parameters like other languages, so the only way would be an Option that would break compat with the current API - or extending IniDefault which is already quite encompassing of features.

[vthib]

For us this is a needed feature, on windows we want to use CRLF line endings.

I see several possibilities for this feature:

• do not expose any options, but change behavior to use CRLF on windows, LF anywhere else. This is a breaking change, but aligns on python's behavior afaict
• expose a new option in IniDefault to configure the line endings. Yes it adds yet another parameters in this object, but since #22, this is not a breaking change, and adding more fields to this object does not impact the end user.
• do both: expose an option, but by default decide depending on the platform
• last option if you do not want to add more fields to IniDefault would be to add a set_line_endings to Ini, though it looked like you designed all parameters to be settable through the IniDefault struct.

Also, #22 was done to allow adding more parameters to IniDefault without breaking the API, so not wanting to bloat IniDefault more goes a bit in another direction design-wise

[QEDK]

For us this is a needed feature, on windows we want to use CRLF line endings.

I see several possibilities for this feature:

* do not expose any options, but change behavior to use CRLF on windows, LF anywhere else. This is a breaking change, but aligns on python's behavior afaict

* expose a new option in IniDefault to configure the line endings. Yes it adds yet another parameters in this object, but since [Non exhaustive IniDefault #22](https://github.com/QEDK/configparser-rs/pull/22), this is not a breaking change, and adding more fields to this object does not impact the end user.

* do both: expose an option, but by default decide depending on the platform

* last option if you do not want to add more fields to IniDefault would be to add a `set_line_endings` to `Ini`, though it looked like you designed all parameters to be settable through the IniDefault struct.

Also, #22 was done to allow adding more parameters to IniDefault without breaking the API, so not wanting to bloat IniDefault more goes a bit in another direction design-wise

I agree but line endings are low on the list of things that will cause things to break (on a modern version of Windows atleast). I think we can add something like this, similar to your first suggested option:

#[cfg(windows)]
const LINE_ENDING: &'static str = "\r\n";
#[cfg(not(windows))]
const LINE_ENDING: &'static str = "\n";

Edit: Upon further thought and research, most of the Windows ecosystem (i.e. VSCode really) have all adapted to using LF (including Notepad in 2018). Unless, I have an example of this breaking something somewhere, we don't really need this.

[roblabla]

Edit: Upon further thought and research, most of the Windows ecosystem (i.e. VSCode really) have all adapted to using LF (including Notepad in 2018). Unless, I have an example of this breaking something somewhere, we don't really need this.

This is not true in my case. At least on my product, I have lots of users on versions of windows that don't universally support CRLF line endings. For instance, I have clients using Windows Server 2016 and Windows 10 Enterprise LTSC 2016, and various versions of windows 8-8.1 (all of which still supported by microsoft). VSCode does not have the issue, but my users are very unlikely to be using VSCode to edit the ini files (and much more likely to use whatever notepad comes preinstalled on their windows machines).

Setting the line endings based on cfg would work for me. If this is OK with you, I can submit a PR with the change.

[QEDK]

@roblabla @vthib alright, any one of you feel free to pick this up. thanks a lot for your patience and work 😄

[vthib]

Thanks for coming back to this :) . However I see you have released 3.0.0 and marked this for 3.0.1, and the cfg solution that I pushed is a breaking change. I'm not sure how you prefer to tackle this

[QEDK]

Thanks for coming back to this :) . However I see you have released 3.0.0 and marked this for 3.0.1, and the cfg solution that I pushed is a breaking change. I'm not sure how you prefer to tackle this

We'll go with the Pythonic approach of setting the ending per platform, it shouldn't be a breaking change as Rust fs treats CRLF as LF when ingesting it.