volta
volta copied to clipboard
volta-cli
Is there no command line upgrade?
I think it's better to be opinionated and discourage/disallow the use of tabs. If there are places in Nixpkgs that use tabs, they should be fixed.
I think it's better to be opinionated and discourage/disallow the use of tabs. If there are places in Nixpkgs that use tabs, they should be fixed.
What's the benefit of discouraging tabs?
I know a number of languages that recommend using spaces to indent, but none that outright require it.
As far as I'm aware, this is the only place where the nix language cares about whitespace. I personally like to (ab)use elastic tabstops, so having to switch only when writing indented strings in personal derivations is a bit annoying. It isn't breaking anything, but it does make writing .nix feel a little awkward compared to other languages. Maybe some sort of opinionated nix fmt instead would work to ensure consistency across nixpkgs? It seems like some maintainers are already using a nix formatter, since that would explain the packages mentioned above using tabs in indented strings but spaces everywhere else (most tellingly in the ignored last line of indented strings).
Plus, since this would make the behavior of indented strings work consistently with tabs, a formatter would be able to replace tabs with spaces in indented strings without changing behavior.
@edolstra could you please expand a bit? Because in another place, you opposed the simplest available way to ensure syntactic consistency…
Well, at least with spaces and tabs we hopefully won't get a limitation that makes the encouraged option inevitably suboptimal for the most frequent use case.
If tabs aren't stripped, I suggest updating https://github.com/NixOS/nix/blob/6924bdf2bf8f50f2e6ec5d490571594450aba13a/doc/manual/expressions/language-values.xml#L113-L115
, since tabs are indentation, but multiline literals in tab-formatted file don't work as I would expect from reading that.
Maybe even make tabs a syntax error, if using them is going to subtly change the meaning of expressions. (I just spent a few minutes figuring out why two identical-looking pieces of code had different outputs...)
Nix is also used in user configurations, that don't need to adhere to nixpkgs guidelines. So for a better user experience, I would kindly request that this gets merged.
For consistency in nixpkgs, the CI tools can check that edited files contain only spaces for indentation.
This has been confusing me for years because I was wondering why the docs said that indentation would be stripped however I was still seeing indentation in my output. This should definitely fixed. Enforcing an indentation style on nixpkgs can be done with a simple linter (and be more effective) however there is no reason to prevent tabs for personal nix configs especially when it is a source of confusion.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
How about outputting a warning that tabs should not be used in nix definition files, for consistency?
For reference, issue #3759 is also about this topic. Note that other line terminators (i.e. CRLF) also seem to “break” indented strings.
Is this discussion still active? I do not understand why only spaces would be stripped when there is a well understood concept of "Whitespace" (see every regex dialect), I don't want nixpkgs strict style guidelines to be forced onto me in my own personal repos where I choose to use tabs for my own reasons, I should be able to do that. Furthermore if it is to be arbitrarily limited to spaces only, the doco should be updated because stating that "whitespace" is removed is misleading.
-
Can't do in its current form because it would be a breaking language change, and we can't do those until https://github.com/NixOS/rfcs/pull/137 is resolved
-
We can however do a warning on tabs, so
-
users are encouraged to match the rest of the ecosystem
-
users are informed that tab indentation in multiline string indents will have surprising behavior
-
If we do add a warning we need to find a way to make it relatively subtle. Probably would need to be dismissable. The last thing I want is some log noise during every Nix evaluation.
I do agree that if a versioning system is likely to land it would be a good way to roll this out.
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/2023-07-14-nix-team-meeting-minutes-71/30472/1
We can however do a warning on tabs
And please also add a warning on CRLF (and CR), since they cause the same problem. While it is probably less common to use CRLF than tabs in the Linux ecosystem, I guess adding this check in addition to the check for tabs shouldn't be that complicated. [EDIT: Also, if you somehow end up with CRLF, it is often less visible than tabs. Many editors will just start using CRLF for each line termination if they find one occurrence in the file. Some editors[^1] will not even show you an indication which line termination they are using.]
[^1]: I think I even experienced vim not showing me any indication that it is using CRLF for a file while using the default configuration of some Linux distribution, but not sure.
FYI, I don't know why CRLF breaks indented string since the CR (\r) is at the end of the line, not at the beginning, but it does.
It's probably a good thing to eliminate "surprising behavior" where possible, rather than warn about it IMO. If RFC 137 succeeds, that sounds like the better route to me.
I don't think this will threaten ecosystem consistency, given that nixpkgs and every nix formatter I have seen uses spaces.
Marked as draft because this is either blocked on RFC 137 for supporting breaking language changes, or this could be converted to a change that warn appropriately when such tabs are encountered.
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/satisfaction-survey-from-the-new-rfc-166-formatting/49758/37