New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Create Editorconfig File as Part of Cargo Project #2549

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
7 participants
@Voultapher

Voultapher commented Sep 23, 2018

Rendered

@KrishnaSannasi

This comment has been minimized.

Show comment
Hide comment
@KrishnaSannasi

KrishnaSannasi Sep 23, 2018

What do I put here?

You can put a link to the RFC file, 0000-cargo-editorconfig.md

Traditionally this is called Rendered

KrishnaSannasi commented Sep 23, 2018

What do I put here?

You can put a link to the RFC file, 0000-cargo-editorconfig.md

Traditionally this is called Rendered

@Centril Centril added the T-cargo label Sep 23, 2018

@joshtriplett

This comment has been minimized.

Show comment
Hide comment
@joshtriplett

joshtriplett Sep 24, 2018

Member

First of all, thank you for the contribution.

However, as discussed in the pre-RFC thread, I don't think this is a good idea to do by default. Having a cargo option to enable this, or putting it in a cargo template, or similar mechanisms all seem fine.

Among other things:

  • Many editors already have this as the default configuration for Rust; this configuration would be redundant in that case.
  • Adding such default configuration to any editors that don't already have it would address this issue for every project, without needing these files. At that point, the editorconfig files would be entirely redundant, and would have spread through the ecosystem.
  • Of the editors mentioned that have editorconfig support, while "several" support it without plugins, many just have it as a plugin that requires installation and enabling, so counting that as "support" doesn't seem appropriate. What subset of editors would this "work out of the box" for?
  • This adds an extra file in the repository, and the first one not required to build the project. (Hence the suggestion above to make this optional and disabled by default.)
  • For projects that use rustfmt / cargo fmt, this would be redundant, and would add an extra place to change settings separate from rustfmt.toml.
  • Ironically, this might well make it more likely that people would diverge from the standard Rust style, since it has the defaults visible right there for editing.
  • The user may already have a prevailing style configured as part of a higher-level project, and this would override that.
  • While we can hope that most projects follow the prevailing Rust style, attempting to enforce that style via editor configuration seems likely to generate at least some surprise and pushback. Imagine, for instance, a large existing project with a standard style, who intend to use that same style for Rust code. On balance, I don't want anyone's first exposure to Rust to be tainted by a negative impression of "oh, this language is opinionated about formatting". The high cost of that, versus the minor annoyance of some projects diverging from the standard Rust style, does not favor a change like this.

Separately from that, an issue with the proposed defaults:

  • This should not apply to *, only to *.rs and *.toml.
Member

joshtriplett commented Sep 24, 2018

First of all, thank you for the contribution.

However, as discussed in the pre-RFC thread, I don't think this is a good idea to do by default. Having a cargo option to enable this, or putting it in a cargo template, or similar mechanisms all seem fine.

Among other things:

  • Many editors already have this as the default configuration for Rust; this configuration would be redundant in that case.
  • Adding such default configuration to any editors that don't already have it would address this issue for every project, without needing these files. At that point, the editorconfig files would be entirely redundant, and would have spread through the ecosystem.
  • Of the editors mentioned that have editorconfig support, while "several" support it without plugins, many just have it as a plugin that requires installation and enabling, so counting that as "support" doesn't seem appropriate. What subset of editors would this "work out of the box" for?
  • This adds an extra file in the repository, and the first one not required to build the project. (Hence the suggestion above to make this optional and disabled by default.)
  • For projects that use rustfmt / cargo fmt, this would be redundant, and would add an extra place to change settings separate from rustfmt.toml.
  • Ironically, this might well make it more likely that people would diverge from the standard Rust style, since it has the defaults visible right there for editing.
  • The user may already have a prevailing style configured as part of a higher-level project, and this would override that.
  • While we can hope that most projects follow the prevailing Rust style, attempting to enforce that style via editor configuration seems likely to generate at least some surprise and pushback. Imagine, for instance, a large existing project with a standard style, who intend to use that same style for Rust code. On balance, I don't want anyone's first exposure to Rust to be tainted by a negative impression of "oh, this language is opinionated about formatting". The high cost of that, versus the minor annoyance of some projects diverging from the standard Rust style, does not favor a change like this.

Separately from that, an issue with the proposed defaults:

  • This should not apply to *, only to *.rs and *.toml.
@Voultapher

This comment has been minimized.

Show comment
Hide comment
@Voultapher

Voultapher Sep 24, 2018

First of all, thank you for your feedback :)

Many editors already have this as the default configuration for Rust; this configuration would be redundant in that case.

I tried vim, atom and notepad++, none of them were consistent here without editorconfig.

Adding such default configuration to any editors that don't already have it would address this issue for every project, without needing these files. At that point, the editorconfig files would be entirely redundant, and would have spread through the ecosystem.

As said in the RFC, that would be great, yet that is far away, let's not ignore a realistic solution in favor of some hypothetical future.

Of the editors mentioned that have editorconfig support, while "several" support it without plugins, many just have it as a plugin that requires installation and enabling, so counting that as "support" doesn't seem appropriate. What subset of editors would this "work out of the box" for?

See the incomplete list of no plugin required here https://editorconfig.org/:

  • GitHub
  • Gogs
  • IntelliJIdea
  • KtextEditor
  • Komodo
  • Kakoune
  • VisualStudio
  • PyCharm
  • ReSharper
  • Rider
  • RubyMine
  • SourceLair
  • TortoiseGit
  • WebStorm
  • Kate

Normalized by usage, using this survey editorconfig is supported by 98.4% of development environments and rustfmt by 37.8% for web developers and 98.7% vs 28.3% for desktop developers respectively. That is a very big difference!

Avoiding a solution for 2/3 of the community only because there might be support for rustfmt at some point in the future seems like a poor decision.

This adds an extra file in the repository, and the first one not required to build the project. (Hence the suggestion above to make this optional and disabled by default.)

Vcs git is required for building?

For projects that use rustfmt / cargo fmt, this would be redundant, and would add an extra place to change settings separate from rustfmt.toml.

Indeed that's unfortunate, one option would be to add warnings in rustfmt about this. Parsing editorconfig files should be relatively simple, plus there are already crates for this in the wild.

Ironically, this might well make it more likely that people would diverge from the standard Rust style, since it has the defaults visible right there for editing.

This is about psychology, if you have someone likely to change the defaults, I speculate they will also not be the people that use rustfmt with default settings, and at least with editorconfig they documented their change, and when I open a pull request for their project. I can avoid some needless friction.

The user may already have a prevailing style configured as part of a higher-level project, and this would override that.

All editors with editorconfig, be it default or with plugin, show an icon that editorconfig is active for the file. If the style conflicts with their previous style, they have the option to change editorconfig to match their previous style or remove the file. Both are very easy and shouldn't take much time. As always for defaults it is about finding the most common use case and expressing them without cannibalizing corner cases.

On balance, I don't want anyone's first exposure to Rust to be tainted by a negative impression of "oh, this language is opinionated about formatting". The high cost of that, versus the minor annoyance of some projects diverging from the standard Rust style, does not favor a change like this.

That argument seems very inconsistent, the rust book mentions the opinionated rust style in the first chapter at 'Hello World':

There are four important details to notice here. First, Rust style is to indent with four spaces, not a tab.

Either we as a community express opinionated formatting, or we don't. Saying we do in the rust book which is and should be the entry point for most people, and then shying away from expressing this in a configuration file seems off.

This should not apply to *, only to *.rs and *.toml.

Editorconfig essentially only applies to files that are being edited, which usually means source code. Still, you are right, indent size and style and trim trailing whitspace can cause issues in other files. For example in markdown trailing whitespace has an impact on formatting.
How about:

# https://editorconfig.org
root = true

[*]
charset = utf-8
end_of_line = lf

[*.{rs,toml}]
indent_size = 4
indent_style = space
insert_final_newline = true
trim_trailing_whitespace = true

This way a uncontroversial subset is applied to everything, and the opinionated things only apply for rust files. Of course there are cases where the global rules could be problematic, however they seem very corner case, and as said above in those cases, the user can edit or remove this file.

Voultapher commented Sep 24, 2018

First of all, thank you for your feedback :)

Many editors already have this as the default configuration for Rust; this configuration would be redundant in that case.

I tried vim, atom and notepad++, none of them were consistent here without editorconfig.

Adding such default configuration to any editors that don't already have it would address this issue for every project, without needing these files. At that point, the editorconfig files would be entirely redundant, and would have spread through the ecosystem.

As said in the RFC, that would be great, yet that is far away, let's not ignore a realistic solution in favor of some hypothetical future.

Of the editors mentioned that have editorconfig support, while "several" support it without plugins, many just have it as a plugin that requires installation and enabling, so counting that as "support" doesn't seem appropriate. What subset of editors would this "work out of the box" for?

See the incomplete list of no plugin required here https://editorconfig.org/:

  • GitHub
  • Gogs
  • IntelliJIdea
  • KtextEditor
  • Komodo
  • Kakoune
  • VisualStudio
  • PyCharm
  • ReSharper
  • Rider
  • RubyMine
  • SourceLair
  • TortoiseGit
  • WebStorm
  • Kate

Normalized by usage, using this survey editorconfig is supported by 98.4% of development environments and rustfmt by 37.8% for web developers and 98.7% vs 28.3% for desktop developers respectively. That is a very big difference!

Avoiding a solution for 2/3 of the community only because there might be support for rustfmt at some point in the future seems like a poor decision.

This adds an extra file in the repository, and the first one not required to build the project. (Hence the suggestion above to make this optional and disabled by default.)

Vcs git is required for building?

For projects that use rustfmt / cargo fmt, this would be redundant, and would add an extra place to change settings separate from rustfmt.toml.

Indeed that's unfortunate, one option would be to add warnings in rustfmt about this. Parsing editorconfig files should be relatively simple, plus there are already crates for this in the wild.

Ironically, this might well make it more likely that people would diverge from the standard Rust style, since it has the defaults visible right there for editing.

This is about psychology, if you have someone likely to change the defaults, I speculate they will also not be the people that use rustfmt with default settings, and at least with editorconfig they documented their change, and when I open a pull request for their project. I can avoid some needless friction.

The user may already have a prevailing style configured as part of a higher-level project, and this would override that.

All editors with editorconfig, be it default or with plugin, show an icon that editorconfig is active for the file. If the style conflicts with their previous style, they have the option to change editorconfig to match their previous style or remove the file. Both are very easy and shouldn't take much time. As always for defaults it is about finding the most common use case and expressing them without cannibalizing corner cases.

On balance, I don't want anyone's first exposure to Rust to be tainted by a negative impression of "oh, this language is opinionated about formatting". The high cost of that, versus the minor annoyance of some projects diverging from the standard Rust style, does not favor a change like this.

That argument seems very inconsistent, the rust book mentions the opinionated rust style in the first chapter at 'Hello World':

There are four important details to notice here. First, Rust style is to indent with four spaces, not a tab.

Either we as a community express opinionated formatting, or we don't. Saying we do in the rust book which is and should be the entry point for most people, and then shying away from expressing this in a configuration file seems off.

This should not apply to *, only to *.rs and *.toml.

Editorconfig essentially only applies to files that are being edited, which usually means source code. Still, you are right, indent size and style and trim trailing whitspace can cause issues in other files. For example in markdown trailing whitespace has an impact on formatting.
How about:

# https://editorconfig.org
root = true

[*]
charset = utf-8
end_of_line = lf

[*.{rs,toml}]
indent_size = 4
indent_style = space
insert_final_newline = true
trim_trailing_whitespace = true

This way a uncontroversial subset is applied to everything, and the opinionated things only apply for rust files. Of course there are cases where the global rules could be problematic, however they seem very corner case, and as said above in those cases, the user can edit or remove this file.

@joshtriplett

This comment has been minimized.

Show comment
Hide comment
@joshtriplett

joshtriplett Sep 24, 2018

Member
Member

joshtriplett commented Sep 24, 2018

@nrc

This comment has been minimized.

Show comment
Hide comment
@nrc

nrc Sep 24, 2018

Member

Having a cargo option to enable this, or putting it in a cargo template, or similar mechanisms all seem fine.

I think having this in some kind of template is the best solution. I fear that there are lots of things various people would like cargo new to do, and adding them all, even as off-by-default options does not scale well.

This would also be a little difficult for Rustfmt. If there is an editorconfig file and a rustfmt.toml, which setting should win? If Rustfmt is used via an editor and the user changes the configuration, should that override a setting in the rustfmt.toml (we do this via the RLS, and it is controversial to say the least. Adding another source of defaults, seems to complicate things even more).

Member

nrc commented Sep 24, 2018

Having a cargo option to enable this, or putting it in a cargo template, or similar mechanisms all seem fine.

I think having this in some kind of template is the best solution. I fear that there are lots of things various people would like cargo new to do, and adding them all, even as off-by-default options does not scale well.

This would also be a little difficult for Rustfmt. If there is an editorconfig file and a rustfmt.toml, which setting should win? If Rustfmt is used via an editor and the user changes the configuration, should that override a setting in the rustfmt.toml (we do this via the RLS, and it is controversial to say the least. Adding another source of defaults, seems to complicate things even more).

@Voultapher

This comment has been minimized.

Show comment
Hide comment
@Voultapher

Voultapher Sep 26, 2018

Having gained a better understanding of the situation, I agree that adding editorconfig by default would be too much.

Regarding cargo templates, there seem to be several tickets for it, with the most recent I found: rust-lang/cargo#5151. Are there supposed to be some default templates?

I genuinely appreciate the goal of trying to provide defaults that work
well for people. I feel that creating a new file in every new project is
too much.

It still feels unsatisfying, I believe we can do more here than we are currently doing.

For me it's less about enforcing the same style everywhere, I personally don't care too much about the style, it's more about removing friction when contributing to other projects. It's situations like these unbit/uwsgi#1719, that waste time without adding anything valuable. Give me some way to easily use your style. Editorconfig is great for this.

One idea to mitigate this problem, would be to add a crates.io lint that checks 2 things, is the style consistent across some metrics for *.rsand *.toml files, and is the style if consistent expressed somehow, ideally as rustfmt default or via customized rustfmt.toml.

This creates 3 possibilities:

  • The style is consistent and matches rustfmt defaults
  • The style is consistent and matches a custom style config, expressed in something like rustfmt.toml
  • The style is inconsistent

Of course consistency is not black and white it would most likely have to be a heuristic, partial results could also be displayed as such, 'matches rustfmt 97%'.

To make this information obvious to crates.io users, it could be encoded as a badge, as example:

  • No badge or [rustfmt consistent] green
  • [custom rustfmt consistent] neutral color or also green
  • [inconsistent formatting] red color

This would be setting the bar higher for projects that are open source and expect to be used and contributed to, by the community, which is my understanding of what crates.io is for. This way both crate maintainers and crate users are more aware of the situation. If we use this consistency score to influence crates.io searches, a potential side effect could be, that crate maintainers that want their crate to be popular would care about having some form of consistent style. Of course this could go horribly wrong, by making the crates.io contribution entry barrier feel needlessly high.

Voultapher commented Sep 26, 2018

Having gained a better understanding of the situation, I agree that adding editorconfig by default would be too much.

Regarding cargo templates, there seem to be several tickets for it, with the most recent I found: rust-lang/cargo#5151. Are there supposed to be some default templates?

I genuinely appreciate the goal of trying to provide defaults that work
well for people. I feel that creating a new file in every new project is
too much.

It still feels unsatisfying, I believe we can do more here than we are currently doing.

For me it's less about enforcing the same style everywhere, I personally don't care too much about the style, it's more about removing friction when contributing to other projects. It's situations like these unbit/uwsgi#1719, that waste time without adding anything valuable. Give me some way to easily use your style. Editorconfig is great for this.

One idea to mitigate this problem, would be to add a crates.io lint that checks 2 things, is the style consistent across some metrics for *.rsand *.toml files, and is the style if consistent expressed somehow, ideally as rustfmt default or via customized rustfmt.toml.

This creates 3 possibilities:

  • The style is consistent and matches rustfmt defaults
  • The style is consistent and matches a custom style config, expressed in something like rustfmt.toml
  • The style is inconsistent

Of course consistency is not black and white it would most likely have to be a heuristic, partial results could also be displayed as such, 'matches rustfmt 97%'.

To make this information obvious to crates.io users, it could be encoded as a badge, as example:

  • No badge or [rustfmt consistent] green
  • [custom rustfmt consistent] neutral color or also green
  • [inconsistent formatting] red color

This would be setting the bar higher for projects that are open source and expect to be used and contributed to, by the community, which is my understanding of what crates.io is for. This way both crate maintainers and crate users are more aware of the situation. If we use this consistency score to influence crates.io searches, a potential side effect could be, that crate maintainers that want their crate to be popular would care about having some form of consistent style. Of course this could go horribly wrong, by making the crates.io contribution entry barrier feel needlessly high.

@joshtriplett

This comment has been minimized.

Show comment
Hide comment
@joshtriplett

joshtriplett Sep 26, 2018

Member

We discussed this in the @rust-lang/cargo meeting today.

We were quite receptive to the motivation and intention of this proposal, but we'd like to keep cargo new only creating the minimal files needed for a new Rust project. Anything beyond that should be the domain of a project template.

(For the record, we also explicitly discussed that the default of --git doesn't necessarily fit that policy. Nonetheless, that's the existing behavior and widespread expectation.)

@rfcbot fcp close

Member

joshtriplett commented Sep 26, 2018

We discussed this in the @rust-lang/cargo meeting today.

We were quite receptive to the motivation and intention of this proposal, but we'd like to keep cargo new only creating the minimal files needed for a new Rust project. Anything beyond that should be the domain of a project template.

(For the record, we also explicitly discussed that the default of --git doesn't necessarily fit that policy. Nonetheless, that's the existing behavior and widespread expectation.)

@rfcbot fcp close

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Sep 26, 2018

Team member @joshtriplett has proposed to close this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

rfcbot commented Sep 26, 2018

Team member @joshtriplett has proposed to close this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@carols10cents

This comment has been minimized.

Show comment
Hide comment
@carols10cents

carols10cents Sep 26, 2018

Member

I'm no longer on the cargo team; how do I get off the rfcbot list? I've manually removed myself from the ticky boxes list.

Member

carols10cents commented Sep 26, 2018

I'm no longer on the cargo team; how do I get off the rfcbot list? I've manually removed myself from the ticky boxes list.

@Centril

This comment has been minimized.

Show comment
Hide comment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment