Languages: support specifying what's included in standardized way #1974
Conversation
Deploying devenv with
|
| Latest commit: |
3e25da4
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://db572188.devenv.pages.dev |
| Branch Preview URL: | https://languages-overhaul.devenv.pages.dev |
Add comprehensive devtools configuration options across all language modules, including: - New languages: Ada, Assembly, COBOL, MATLAB, SQL, Visual Basic - Enhanced dev support for existing languages with LSPs, formatters, linters, and debuggers - Standardized module structure with consistent languages.X.dev.enable pattern - Improved documentation and package organization
domenkozar
force-pushed
the
languages-overhaul
branch
from
3f3093b to
3ac53e7
Compare
| enable = lib.mkOption { | ||
| type = lib.types.bool; | ||
| default = true; | ||
| description = "Enable black formatter."; |
There was a problem hiding this comment.
| description = "Enable black formatter."; | |
| description = "Enable the formatter (e.g. `black`, `ruff` etc.)"; |
| type = lib.types.package; | ||
| default = cfg.package.pkgs.black; | ||
| defaultText = lib.literalExpression "cfg.package.pkgs.black"; | ||
| description = "The black package to use."; |
There was a problem hiding this comment.
| description = "The black package to use."; | |
| description = "The package to use."; |
| type = lib.types.package; | ||
| default = cfg.package.pkgs.ruff; | ||
| defaultText = lib.literalExpression "cfg.package.pkgs.ruff"; | ||
| description = "The ruff package to use."; |
There was a problem hiding this comment.
| description = "The ruff package to use."; | |
| description = "The linter package to use."; |
| type = lib.types.package; | ||
| default = cfg.package.pkgs.mypy; | ||
| defaultText = lib.literalExpression "cfg.package.pkgs.mypy"; | ||
| description = "The mypy package to use."; |
There was a problem hiding this comment.
| description = "The mypy package to use."; | |
| description = "The type-check package to use."; |
| type = lib.types.package; | ||
| default = cfg.package.pkgs.pytest; | ||
| defaultText = lib.literalExpression "cfg.package.pkgs.pytest"; | ||
| description = "The pytest package to use."; |
There was a problem hiding this comment.
| description = "The pytest package to use."; | |
| description = "The test-runner package to use."; |
| enable = lib.mkOption { | ||
| type = lib.types.bool; | ||
| default = true; | ||
| description = "Enable debugpy debugger."; |
There was a problem hiding this comment.
| description = "Enable debugpy debugger."; | |
| description = "Enable the debugger."; |
| enable = lib.mkOption { | ||
| type = lib.types.bool; | ||
| default = true; | ||
| description = "Enable python-lsp-server language server."; |
There was a problem hiding this comment.
| description = "Enable python-lsp-server language server."; | |
| description = "Enable the python language server."; |
| type = lib.types.package; | ||
| default = cfg.package.pkgs.python-lsp-server; | ||
| defaultText = lib.literalExpression "cfg.package.pkgs.python-lsp-server"; | ||
| description = "The Python LSP package to use. Can be changed to pyright, jedi-language-server, or other LSP implementations."; |
There was a problem hiding this comment.
| description = "The Python LSP package to use. Can be changed to pyright, jedi-language-server, or other LSP implementations."; | |
| description = "The Python LSP package to use. Can be changed to `pyright`, `jedi-language-server`, or other LSP implementations."; |
| enable = lib.mkOption { | ||
| type = lib.types.bool; | ||
| default = true; | ||
| description = "Enable rust-analyzer language server."; |
There was a problem hiding this comment.
@domenkozar : Its tedious I know, but I suggest that these documentation strings are always kind of generic and do not mention the implementation. I made some suggestions in the python.nix`. That would be cool and more streamlined.
| description = "The delve package to use."; | ||
| }; | ||
| }; | ||
|
|
There was a problem hiding this comment.
suggestion: As I want other tools to be compiled with buildWithSpecificGo. The user of this module would like to specify a bunch of other "go" tools which should be modified. I guess here I can add tools.packages from my PR which just is a bunch of other derivations which are modified with buildWithSpecificGo. Or we make buildWithSpecificGo public for users to use as well in .packages = [ cfg.languages.go.lib.buildWithSpecificGo ]; The question then comes how/where to export this public function for the language go? 😄 .
- I like the public
buildWithSpecificGobetter since then users can use it as they like.
There was a problem hiding this comment.
@domenkozar : See the example above:
- linters: all tools which suggest code-changes but do not change it (?).
- formatters: all tools which do code-changes ...
- tools: all other stuff which are not clear (should we only have that?)
what goes into what is hard (?) or isnt it?
lsp, and debugger are bomb-proof.
From a user perspective it would be nice to have the ability to
- enable linters or formatters
- override
enable/packagefor certain stuff.
Maybe
dev.formatter = { # will define a bunch of tools by default.
# disables that category in total, doing nothing (defaulted to `true`)
enable = true;
# Switches all `enable` to `true/false`, giving you full control what packages you want. (defaulted to `true`).
defaults.enable = false;
tools = { # freeform module matching the key to the enabled default linters)
gofmt = {
enable = true;
package = pkgs.bla;
};
golines = {
enable = true;
};
mytool = { }; # eval. error, is not in the list of derivations supported on this.
}
}
dev.linter = {
# same as above.
}
dev.tools = {
# same as above.
}The question is can tools be implemented somehow work, it will take each key,value and merge it with the stuff which dev.formatter defaults to.
There was a problem hiding this comment.
I've also been thinking about all of this since seeing your tools PR for go.
I'm also leaning towards a freeform module structure that we can share across languages, with predefined options for each. This would be similar to the structure we currently use for git-hooks. A lot of languages lack standardization for tooling and may have several (if not more) competing or complementary solutions: Haskell, Python, JavaScript, etc. This makes a single global toggle unviable.
Generic tooling is also worth discussing. The currently drop a pre-defined and largely undocumented bundle into the shell. I'd like to see a way have more control over what's added and ensure that it is documented.
This PR introduces a comprehensive overhaul of the language modules, adding standardized development tool support across
all languages and introducing several new language modules.
Fixes #783
New Languages Added
Enhanced Development Tool Support
All existing language modules now feature a standardized
languages.<lang>.dev.enableconfiguration with:languages.<lang>.dev.lsp.enablelanguages.<lang>.dev.formatter.enablelanguages.<lang>.dev.linter.enablelanguages.<lang>.dev.debugger.enable