[TOML stdlib] Write toml files with \r\n line endings on Windows

[davidanthoff]

I think the ideal situation would be:

1. if the file already exists on disc, and you update it, use the same line ending style that is used in the file already
2. if it is a new file, use the platform default line ending (i.e. \r\n on Windows, \n everywhere else)

The main benefit would be that if these files are under git version control, and one has installed git with the default settings on Windows, then things are easier if these files have \r\n line endings: if I checkout a repo with these files in it, git will create these files with \r\n endings, because they are detected as a text file. If I then do say a update, then the file gets rewritten, but now with a \n line ending, even if nothing else changed. Then git shows me the file as modified, but the only change is the line ending, which is kind of annoying.

[StefanKarpinski]

Do you have git setup to checkout text files with CRLF line endings?

[davidanthoff]

Yes, that is the default you get on Windows. The git setup presents that as the recommended option, so I would expect that most users on Windows run with that setting.

[StefanKarpinski]

Maybe we can just respect the git setting since Pkg is already git-aware.

[davidanthoff]

Was this fixed?

[davidanthoff]

@fredrikekre bump, just curios, was this fixed and therefore closed?

[fredrikekre]

Don't know. Closed since there is no TOML code here any more.

[davidanthoff]

I guess the first step would be to add a line-ending option to TOML.jl, but then there would still have to be work done here in Pkg.jl that controls what kind of line-ending should be used in a given write? So it seems to me that this issue here should stay open.

[StefanKarpinski]

This feature seems kind of fiddly. The \r\n line ending convention is kind of a relic at this point. There is one true text file format, especially for source code: UTF-8 with \n newlines. Most dev tools support this these days, even on Windows. We can certainly support reading \r\n line endings (and we already do), but it seems far better if there is one canonical output format for each TOML file, not different optional variations on it. It seems like we could recommend that people use core.autocrlf = input so that everything is checked-out as-is, but if any editors introduce \r\n line endings, git will automatically convert them to \n before committing.

[davidanthoff]

The \r\n line ending convention is kind of a relic at this point.

I think that is really not true on Windows. If you just use git with the default configuration on Windows, all your text files will have \r\n line endings. Same is true for VS Code on Windows: you create a new file, it is CRLF by default. I don't think we should encourage all Julia users on Windows to change a global git configuration setting for things to work well, because a) we'll never be able to get that message to everyone, and b) the setting also applies to anything non-Julia, and so there might be lots of scenarios where people just want to stick with the default for non-Julia reasons. I think at the end of the day Julia should just work smoothly with whatever the default is for git on a given platform.

I think the nicest behavior would be something like this:

• if Pkg.jl edits an existing file, it just uses whatever line-ending was previously used in that file. That is how pretty much all text-editing dev tools on Windows work, AFAIK.
• for creating new files, I'm not sure whether it would make more sense to just always use CLRF on Windows, or look at the global git config values and use that.

Yes, that is more involved than one would wish, but I think all text editing tools on Windows just do it that way?

[StefanKarpinski]

Ok, if someone wants to figure out how to read the git setting (via libgit2, presumably?), adding an option to TOML to emit \r\n line endings shouldn't be hard, but figuring out reading the setting should come first since otherwise we don't really need the TOML option.

[KristofferC]

I wrote some stuff here earlier that was a bit wrong. Anyway, I think for existing files just replacating the existing could be done easily. For new files, I think just using \n is fine.

[davidanthoff]

Could we for now just reopen the issue here?

[StefanKarpinski]

Reminder — the next steps (for someone) here are:

1. Figure out how to read the git crlf setting
2. Add a line ending option to TOML
3. Combine the two somehow