search

conan-io / conan

Conan - The open-source C and C++ package manager
https://conan.io
MIT License
8.2k stars 979 forks source link

Lockfile line ending #17139

Open forry opened 6 days ago

forry commented 6 days ago

What is your question?

Hello, is there a way to influence the eol for the lockfile output by conan?

Most of our devs are on Windows thus having git setting core.autocrlf=true (recommended by git doc). Each time the conan install updates the conan.lock (which is each time the cmake configure is run) it generates the LF line endings instead of CRLF. Even if nothing else has changed the git will display it as modified due to different eol.

Thanks

Have you read the CONTRIBUTING guide?

memsharded commented 6 days ago

Hi @forry

I think we kind of disagree with the core.autocrlf=true. That made some sense in the past, when Windows editors didn't support LF and they wanted CRLF. Nowadays, all editors in Windows, even the Notepad support LF. So there is no reason to keep converting and messing with line endings, which can only create issues in case some client configures things incorrectly (like creating massive diffs, etc).

Having different line endings also produces some unwanted and bad side effects read for example https://docs.conan.io/2/knowledge/faq.html#error-obtaining-different-revisions-in-linux-and-windows, will produce different revisions in recipes.

So the recommendation would be to use LF everywhere. All conan created files are LF: generators (CMakeDeps, etc), json files like --format=json for graph, package-lists, graph-build-order, etc, etc.

forry commented 6 days ago

It is not only about editors. Last week one of my colleagues was tracking down an issue with translations. The problem was that on one machine the file didn't have the CRLF ending (due to a git wasn't set up properly) but the legacy code was counting on that.

All conan created files are LF: generators (CMakeDeps, etc), json files like --format=json for graph, package-lists, graph-build-order, etc, etc.

That is fine for us when the files are not part of the repository. Even though I would rather if it would just honour the environment same as most of the tools tries to honour different path separators on different OSes.

So, I can either tell whole company to switch that git config of and see what happens or just always check the conan.lock and ignore it if there are no "real" changes. Is there perhaps some way through the hooks? I couldn't find any, but maybe there is.

Thanks

memsharded commented 6 days ago

That is fine for us when the files are not part of the repository. Even though I would rather if it would just honour the environment same as most of the tools tries to honour different path separators on different OSes.

It was done that way in Conan 1. And it was removed for being more problematic than helpful. Creating all files with LF only has proven to work better in practice that the opposite. The path separators on different OSs is a great example. If there was a common syntax that would work in all OS, it would be the one that we would use, having to maintain and deal with the path separators issue is a nightmare that makes things always more fragile and with more issues.

To explain our experience, the thing is that we would also get the opposite complains, if Conan was generating some of the files with different line ending in different platforms, users will complain that Conan is not being consistent, and there is no reason to generate the same file in different platforms with different line endings, as that messes unnecessarily and they are now forced to convert it from CRLF to LF to avoid issues.

In any case I am not sure if I understood the pain of the autocrlf=true, it is that the git diff shows more changes that the desired? Maybe using something in the line of git diff --ignore-all-space or the like?