-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add flake-parts
module
#14
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I should read more of the treefmt implementation, but I'm confused by the supposed submodule-ish options in this PR. Doesn't treefmt already do its things in modules, that just need to be imported?
The module options are spread across several files: there is one module called Lines 23 to 25 in 4230552
Is there a straightforward way to "merge" them to produce a single submodule for use in |
Another trick is you could use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice
Because treefmt 0.5 has the fix.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Actually, I found a solution to this: need to move the |
This still won't work; see follow-up commit.
This needed to make it work with `flake-parts`, otherwise we get: error: The option `build.wrapper' is defined multiple times.
flake-module.nix
Outdated
(import ./.).evalModule pkgs config.treefmt.config; | ||
}; | ||
programs = mkOption { | ||
type = types.attrsOf types.package; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
type = types.attrsOf types.package; | |
type = types.listOf types.package; |
A set of all the packages isn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used an attrset rather than a list - because, while the likes of buildInputs
does take a list, in other places attrsets are used.
For example, haskell-flake
's buildTools
is an attrset of packages, because it allows the user to override the default build tools to disable some of them (by setting { foo = null; }
.
buildTools = hp: {
treefmt = config.treefmt.wrapper;
} // config.treefmt.programs;
I also figured it would be nice to "tag" each program with the formatter it is associated with it, so the caller can do any special processing that way. If we make this use listOf
instead, then haskell-template will have to re-implement the logic.
This is ready for review! @zimbatm Let me know what you decide about the type of the |
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
}; | ||
}); | ||
}; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like how smaller this module has become. Nice :)
Maybe a last question to @roberth mostly; given that flake-parts has a global namespace, do you think we should prefix treefmt into something like programs.treefmt
for example?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind a flat namespace at all. And maybe treefmt is more than a program?
In Nixpkgs we're actually trying to get rid of the categorization hierarchy for various reasons. RFC coming soon, but preparations are happening here https://github.com/nixpkgs-architecture/simple-package-paths
Made a PR to add it to flake.parts if that's ok. I'll add a link to the rendered docs there. |
How can I access treefmt itself for interactive usage? |
Would it make sense to add this output? |
@Mic92 Does https://flake.parts/debug.html help? I feel like unconditionally adding |
I think instead of a package it could also become module documentation (i.e. an example that adds the wrapped treefmt to a devshell) but just now it is not very visible without digging into the code how one can access treefmt otherwise. |
I'm opening a draft PR (instead of waiting for full implementation) just to get something working, as well as to get any early feedback. The commits in this PR can be squash merged (or I can rebase them if necessary) once ready.
This PR adds a
flake-parts
module for working with treefmt in the most ergonomic way. It also adds a flake check to test in CI that the source tree is formatted. You can see a demo here: srid/haskell-template#75Resolves #1
types.raw
be replaced with appropriate types? See also: API feedback #2