fix: treefmt

[DrTeagle]

As mentioned in my issue, while the check for treefmt.toml makes sense, it fails when the toml file is not there, leading to undesired behavior(as is the case in nix, using either treefmt-nix or nixpkgs.treefmt.withConfig). Marking as draft so that me and @zivarah can discuss over what we should do

[zivarah]

I don't see a link to your issue anywhere so adding one for convenience: #793

I've replied there with some thoughts on the issue itself -- if we decide an upstream change is appropriate then we can discuss further on this PR?

[stevearc]

My understanding is that treefmt-nix is a separate package that installs a treefmt command that does normal treefmt things but integrated with nix. For treefmt-nix, it doesn't require a toml config file because it gets its config from nix. Is that about the shape of the problem?

If that's correct, then I'd either recommend overriding the treefmt formatter in your user config with require_cwd = false, or I could potentially see the case for making another formatter configuration for treefmt_nix.

[zivarah]

My understanding is that treefmt-nix is a separate package that installs a treefmt command that does normal treefmt things but integrated with nix. For treefmt-nix, it doesn't require a toml config file because it gets its config from nix. Is that about the shape of the problem?

Yes -- specifically, treefmt-nix makes an executable called treefmt that is actually just a shell script that calls out into the real treefmt with a generated config file specified as an argument.

If that's correct, then I'd either recommend overriding the treefmt formatter in your user config with require_cwd = false, or I could potentially see the case for making another formatter configuration for treefmt_nix.

Note that any such treefmt_nix formatter would need to use flake.nix as the root marker but also would need something else to understand if treefmt-nix is actually in use. In practice that may involve some flake evaluation depending on the implementation.

I could see a case for some more generic handling in the base treefmt formatter definition based on whether a treefmt executable exists and can be invoked without erroring. My response to #793 does give an example of how I've worked around this in my own config, though as noted there I don't know that it's upstream-ready. I'm curious for your thoughts on that.

[stevearc]

That workaround seems a bit inelegant and I generally don't want to proliferate that kind of logic within conform. If there's really no easy way to tell if treefmt-nix should be used in a directory or not I might suggest that this would best be solved with :help 'exrc'. You can set some directory-specific logic to wire up the formatter the way you need.

[zivarah]

Yeah, I think that makes sense. I'd be in favor of closing the PR and closing #793 as well.

[bmrips]

Note that treefmt-nix sets --tree-root-file=${config.projectRootFile}.