RFC 101/166 style #118
RFC 101/166 style #118
Conversation
To make more clear that one formats and the other one only checks
Tests mostly imported from Alejandra
- Disallow single-line if statements - Handle multi-line conditions differently (indent instead of absorb)
- The (from) case needs to be improved - Somehow it indents the comments *after* the statement now, no idea why or how to fix
The file was identical to diff/idioms_nixos_1 and therefore redundant. Moreover, we need to also keep a look on the *really* big packages in there, and Mozilla is a prime example.
Except when that item is another list or attribute set
This is nixos/modules/services/web-apps/nextcloud.nix, so that we have a big NixOS module in our suite
|
There's a bug in this PR that indents comments too much: Input let
a = null;
# b
in
nullOutput let
a = null;
# b
in
null |
| @@ -0,0 +1 @@ | |||
| use_nix | |||
There was a problem hiding this comment.
Why is this added? Should it be up to the user whether or not they would want to use this specific default Nix shell? Committing this to the repo means anyone with direnv installed is going to get that big red consent message after cd-ing into the project for the first time. This also makes this hard to extend if users have other environment needs & now have to deal with potentially accidentally committing those changes as this personal environment file is now checked into the repository.
I would prefer this be moved to .envrc.example but given it is a single line & those with direnv already know how to use it, a line could be added to the README or flake that says enabling is echo "use flake" > .envrc && direnv allow.
There was a problem hiding this comment.
What about direnv deny? Also works with direnv disallow, direnv block, and direnv revoke
There was a problem hiding this comment.
I honestly don't understand your point. Committing the .envrc file is the point of direnv, to make the developer experience smoother. I love it when projects do that. The shell is additive and not pure, so it will take the outside environment into account.
There was a problem hiding this comment.
direnv deny
This isn’t the experience a user wants. They want to enable direnv, but only after they have a) had time to inspect the .envrc file & b) made modifications for themselves. Current state throws up ANSI red prompt just for cd-ing into the directory. Allow should happen after everything is ready.
the point
Scenario: You and I have different setup needs. I need different environment variables & scripts specific to me. The only way to get them for my personal setup is to edit the .envrc. Now that I have edited the .envrc, git status is saying I have made modification even tho they should be specific to me. I might also accidentally commit those changes as a result since it’s a tracked file. I believe the point is to set up your environment for you, not for everyone as not everyone has the same environment. The point of an .envrc.example is the place for a suggested setup for the average user. cp .envrc.example .envrc is one tiny step. Many projects have .env in their .gitignore because they don’t want to a) check in sensitive env info b) prescribe everyone have the same setup. This is as weird as committing your personal text editor settings… they are your environment settings, not everyone else’s.
love it
I hate it. If I just need to edit a README, I don’t want a direnv prompt, & certainly don’t want to copy down another version of Nixpkgs with tooling I won’t be needing for my task, and definitely not automatically running arbritrary executables I don’t yet understand because I just cloned the repo. I do like it when they offer an example I can copy, or if there is nothing interesting but use flake or use nix, just stick it in the docs.
There was a problem hiding this comment.
This isn’t the experience a user wants.
As a user, I expect that when I install a tool (direnv) and a repo supports it (nixfmt), then the tool should be used. Don't want direnv? Don't install it, then.
I need different environment variables & scripts specific to me
Great, direnv has support for that: $XDG_CONFIG_HOME/direnv/direnvrc and $XDG_CONFIG_HOME/direnv/lib/*.sh. We could also do this but that has security implications.
To be honest, I have never heard from any developer who has direnv installed that they don't want to use it (why did they install it then?). To me it's as simple as:
- Only editing the readme once? Ignore the warning
- Doing something in the repo often?
direnv denyit once. It's quick and easy - Doing something in the repo often but you are like me? Ignore the warning every time
There was a problem hiding this comment.
Also, please don't block this PR on that, I think everyone can handle whatever outcome we end up with 🙈 Thank you for your work!! :)
There was a problem hiding this comment.
To be honest, I have never heard from any developer who has direnv installed that they don't want to use it (why did they install it then?). To me it's as simple as:
- Only editing the readme once? Ignore the warning
- Doing something in the repo often? direnv deny it once. It's quick and easy
- Doing something in the repo often but you are like me? Ignore the warning every time
@dasJ Late to the party, but I just wanted to say I strongly discourage adding .envrc to a git repo (or any other VCS), and it's not about having direnv installed and not wanting to use it btw :) Here are some counter arguments:
- I want to have my own nix shell and env vars when working on this repo (or any other), for which I would like to be in control of my own
.envrcfile.- Specifically on this project, what if I want to use a different Haskell LSP server version? or a different Cabal version? Or if I need some other package in this environment that the project assumes it's globally available?
- I want to be able to source other local files relevant to my environment on that
.envrc, e.g. I use fish shell and it requires some tweaks on certain repos, other folks use zsh or bash, etc.
Having this file committed to the repo removes this flexibility, but it's also easier to argue in its favor for an open source public repo. For private repos there's even more counter arguments, for instance, we have this at work:
- Need to set AWS secrets on a daily basis (lasts 24 hours).
- Need to set specific secrets that last a year (can be sourced from a local file).
- Still need specific Nix shells at times (every project is different).
- Need project-specific env vars that need to change depending on what we are testing and on which environment.
What I suggest instead
Let the users decide what they want available in their environments while still leveraging direnv, be a good citizen and add .envrc to your global .gitignore or add it to the project's .gitignore to avoid anyone adding it back.
There was a problem hiding this comment.
Or if I need some other package in this environment that the project assumes it's globally available?
a good project shell would assume no such things
Regarding credentials: these should not be set in .envrc, but project shell should provide tools (scripts, commands) to manage these
Still need specific Nix shells at times (every project is different).
These can be entered ad-hoc with nix shell\develop
Need project-specific env vars that need to change depending on what we are testing and on which environment.
A command (provided by default dev shell) should be provided to switch between envs
.envrc IMHO should never be edited by devs, it should simply setup all tools needed to work on given project. If customisation of env vars is needed this could be loaded from optional, gitignored file(s)
There was a problem hiding this comment.
a good project shell would assume no such things
This project assumes I need a specific HLS version
Regarding credentials: these should not be set in .envrc, but project shell should provide tools (scripts, commands) to manage these
Agree to disagree. The methods vary across different projects when working on a big organization. A lot of flows are very complex and unfortunately can't be automated, e.g. sign in via SSO behind a VPN, approving the sign in attempt via Okta / Duo, etc. It barely works on Linux, let alone trying to automate these things.
It's much easier on open source public projects, I'll give you that, but private organizations are a completely different story.
These can be entered ad-hoc with nix shell\develop
It doesn't make it easier to pin specific pkgs, add overlays, etc.
A command (provided by default dev shell) should be provided to switch between envs
This isn't bad actually, might work well in some cases, will give it a try :) Certainly not in cases where switching envs requires going through the complex authorization flows, though.
If customisation of env vars is needed this could be loaded from optional, gitignored file(s)
How would you do this if you don't control the content of .envrc?
There was a problem hiding this comment.
We've had this topic at least thrice already. Not sure having this discussion yet another time is a productive use of anybody's time
|
Found a little weirdness here, while formatting my code base: in: (import ./default.nix).devShells.${builtins.currentSystem}.default
or (throw "dev-shell not defined. Cannot find flake attribute devShell.${builtins.currentSystem}.default")out: (import ./default.nix).devShells.${builtins.currentSystem}.default
or (throw "dev-shell not defined. Cannot find flake attribute devShell.${builtins.currentSystem}.default"
) |
|
Oops, most likely this was the case. Never mind then. And thanks to the rfc team for doing this great work. I imagine formatting discussions to be quite tiring. What you are doing is very valuable and will support large amounts of developers not having to waste their time on formatting related discussions anymore or reading badly formatted code. Thanks for pushing this through! You are awesome! |
|
I was just testing out this from nixpkgs together with Seems to be a regression where |
There was a problem hiding this comment.
Overall this is looking okay, so instead of trying to review this in-depth, let's just merge it and iterate with further PRs!
There's still more work to do before the first official release though, see #153 for the overall progress.
|
There's a test failure after the master merge, could you check that out @piegamesde? |
|
Tests now pass, and I can also confirm that the formatting of Nixpkgs has not changed one bit after the master merge, so this is good to go now! |
This reverts commit 5303938. [これ](NixOS/nixfmt#118 入るまでは待つことにする。
This is the experimental branch where we try to implement currently discussed formatting decisions, to get a better feeling of how they affect real-world code.