kamadorueda / alejandra

The Uncompromising Nix Code Formatter

Home Page:https://kamadorueda.github.io/alejandra/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Adhere to [RFC 0166] formatting

nyabinary opened this issue · comments

It's probably a good question for the community once the RFC is adopted, the options are:

  1. make Alejandra follow the suggested style
  2. make Alejandra keep its existing style (there will always be an audience for this style)
  3. archive all alternative formatters so the community only has 1 option available

It's probably a good question for the community once the RFC is adopted, the options are:

1. make Alejandra follow the suggested style

2. make Alejandra keep its existing style (there will always be an audience for this style)

3. archive all alternative formatters so the community only has 1 option available

As I understand 3 is a non-goal, the formatter implementation is supposed to be considered more of a standard specification for formatting, so different implementations could exist as well, 1. Would be the most optimal.

The main intention behind making it a standard is to not make the implementation the standard. This allows some room for both bug fixes and minor improvements, but it also makes it clear which changes need to go though another RFC.

And while Nixpkgs will have to use the official formatter, there's no problem with other standard-complient formatters existing. It would also be possible to change out the underlying implementation of the official formatter (as long as it's standards-compliant).

But I do think that for the benefit of everybody's time, it would be best to archive other formatters if the RFC is accepted and implemented.

But I do think that for the benefit of everybody's time, it would be best to archive other formatters if the RFC is accepted and implemented.

I disagree on this end, I think alejandra should adopt the standard, but some formatters, of course, can be archived like nixpkgs-fmt. Since that had one goal in mind, alejandra is more broad and widely used in the community (including myself) so I think its best to continue supporting it and change it to adhere to the RFC.

If adapting Alejandra to the RFC166 format was easy, I'd already have done so half a year ago. Initially, nixfmt was only our second choice after Alejandra.

If adapting Alejandra to the RFC166 format was easy, I'd already have done so half a year ago. Initially, nixfmt was only our second choice after Alejandra.

What's wrong with Alejandra that makes it harder to adher to RFC0166?

We recorded some meetings notes about that here

@kamadorueda
The time is now to decide I guess, since NixOS/rfcs#166 got officially merged, and their now a tracking issue for nixfmt: NixOS/nixfmt#153

As much as I'd love for us all to fall on a single standard, after trying out the new nixfmt I don't think I'm willing to use an RFC166 compliant formatter on any of my projects. I'd prefer that alejandra remain as it is currently.

As much as I'd love for us all to fall on a single standard, after trying out the new nixfmt I don't think I'm willing to use an RFC166 compliant formatter on any of my projects. I'd prefer that alejandra remain as it is currently.

We could have different modes tbf

We could have different modes tbf

Is anyone actually going to work on and maintain that when there's already alternative formatting tools out there?

It seems to me that alejandra has different goals to RFC 166. If so this should be considered a "won't fix".

After trying nixfmt-rfc-style, I have decided to keep using alejandra in my personal projects. My opinion is that it is ok to have different formatters to choose from, that don't comply with the "standard"