clan/clan-core
11
2
Fork 13
Code Issues 91 Pull Requests 6 Actions Packages Projects 1 Releases Wiki Activity

switch from alejandra -> nixpkgs-fmt #12

Merged
Mic92 merged 1 commits from formatting into main 2023-07-21 09:15:48 +00:00
Conversation 0 Commits 1 Files Changed 11 +64 -65
Mic92 commented 2023-07-21 09:15:41 +00:00
Owner
Copy Link

alejandra has someone questionable choices for formatting that no one would apply to there code if they would format manually.
nixpkgs-fmt seems to produce more readable results.

alejandra has someone questionable choices for formatting that no one would apply to there code if they would format manually. nixpkgs-fmt seems to produce more readable results.
Mic92 added 1 commit 2023-07-21 09:15:42 +00:00 
alejandra has someone questionable choices for formatting that no one would apply to there code if they would format manually.
nixpkgs-fmt seems to produce more readable results.
Mic92 merged commit fb394f29ae into main 2023-07-21 09:15:48 +00:00
Mic92 deleted branch formatting 2023-07-21 09:15:52 +00:00
DavHau reviewed 2023-07-21 09:55:55 +00:00
DavHau left a comment
Owner
Copy Link

I do not want to start a fight about formatters but kindly want to express my disagreement.
I think some of the formatting patterns which nixpkgs adopted from the haskell world are bad for several reasons. Some of them are visible in this diff -> see comments blow.

Anyways, I'm fine with nixpkgs-fmt, if that's the preferred choice of the team.
Currently there is a lot of activity in RFC 101 where they now develop a proper formal standard for nix code formatting.

They currently test their rules on a branch if nixfmt.
I actually just tried it and the formatting choices seem to be a mix between alejandra and nixpkgs-fmt.
Once the standard is out we will have to re-format the whole thing again anyways I guess.

I do not want to start a fight about formatters but kindly want to express my disagreement. I think some of the formatting patterns which nixpkgs adopted from the haskell world are bad for several reasons. Some of them are visible in this diff -> see comments blow. Anyways, I'm fine with nixpkgs-fmt, if that's the preferred choice of the team. Currently there is a lot of activity in [RFC 101](https://github.com/NixOS/rfcs/pull/101) where they now develop a proper formal standard for nix code formatting. They currently test their rules on [a branch if nixfmt](https://github.com/serokell/nixfmt/pull/118). I actually just tried it and the formatting choices seem to be a mix between alejandra and nixpkgs-fmt. Once the standard is out we will have to re-format the whole thing again anyways I guess.
flake-parts/formatting.nix
@ -4,1 +1,3 @@
...
{ self
, inputs
, ...
DavHau commented 2023-07-21 09:33:44 +00:00
Owner
Copy Link

Not sure if that is better? The lines are not conform and start with different characters. You cannot simply re-order the lines without breaking stuff for example.

Not sure if that is better? The lines are not conform and start with different characters. You cannot simply re-order the lines without breaking stuff for example.
flake-parts/formatting.nix
@ -7,3 +6,3 @@
inputs.treefmt-nix.flakeModule
];
perSystem = {pkgs, ...}: {
perSystem = { pkgs, ... }: {
DavHau commented 2023-07-21 09:34:15 +00:00
Owner
Copy Link

Is that really more readable or just more to type?

Is that really more readable or just more to type?
flake.nix
@ -21,0 +16,4 @@
, config
, self
, ...
}: {
DavHau commented 2023-07-21 09:34:33 +00:00
Owner
Copy Link

Is this indentation preferable?

Is this indentation preferable?
Mic92 commented 2023-07-21 11:11:16 +00:00
Author
Owner
Copy Link

fixed in #14

fixed in https://git.clan.lol/clan/clan-core/pulls/14
templates/python-project/shell.nix
@ -5,0 +2,4 @@
, system ? builtins.currentSystem
,
}:
let
DavHau commented 2023-07-21 09:35:20 +00:00
Owner
Copy Link

and this?

and this?
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
backups

   
blog

   
bootstrapping

Issues regarding bootstrapping, or onboarding

  
bug

Something is not working.

  
changes-requested

Please fix this.

  
cli

   
documentation

   
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
facts

Issues regarding facts and secrets setting and generation

  
help wanted

Need some help

  
invalid

Something is wrong

  
Inventory

Inventory

  
low_prio

   
manager

   
modules

   
needs-review

This PR needs to be reviewed. Use the request-changes label to request changes

  
networking

   
packaging

   
question

More information is needed

  
secrets

   
template

Issues regarding templates.

  
test

Issues regarding testing

  
tooling

Issues regarding internal devtools

  
user-testing

Issues that cristallised after hands on user testing.

  
vm

Issues regarding virtual machines.

  
wontfix

This won't be fixed

No Label
backups
blog
bootstrapping
bug
changes-requested
cli
documentation
duplicate
enhancement
facts
help wanted
invalid
Inventory
low_prio
manager
modules
needs-review
networking
packaging
question
secrets
template
test
tooling
user-testing
vm
wontfix
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: clan/clan-core#12
No description provided.
Delete Branch "formatting"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?