Add support for bzlmod #49
Conversation
| w:: "World", | ||
| "Hello": $.w | ||
| w:: 'World', | ||
| Hello: $.w, |
There was a problem hiding this comment.
These examples have been formatted accidentally, but this makes me think: what's the role of example files?
- Are they examples of the output of formatters? (but some files are formatted and some are not)
- Are they examples of input files to the formatters?
In either case I think we could turn them into diff tests, i.e. add pairs (unformatted file, expected output) for each formatter and test whether running bazel-super-formatter with all flags turned on transforms (unformatted file) into (expected output). Of course this will have a side effect of depending on specific formatting behavior exhibited by a given formatter, but in general what we want to test is whether the formatter is run at all by our meta-formatter
| ) | ||
| use_repo(go, "go_sdk") | ||
|
|
||
| non_module_deps = use_extension("//:non_module_deps.bzl", "non_module_deps") |
There was a problem hiding this comment.
perhaps we can start using jvm_rules_external at least in the bzlmod version?
utils/jvm_dependencies.py
Outdated
There was a problem hiding this comment.
another side effect of running bazel-super-formatter on its own repo with all flags turned on
|
|
||
| go = use_extension("@io_bazel_rules_go//go:extensions.bzl", "go_sdk") | ||
| go.download( | ||
| name = "go_sdk", |
There was a problem hiding this comment.
This line causes an error when used from another repo:
Error in fail: go_sdk.download: name must not be specified in non-root module aspect_rules_format
| pip.parse( | ||
| hub_name = "pip", | ||
| python_version = "3.11", | ||
| requirements_lock = "//:requirements_lock.txt", |
There was a problem hiding this comment.
How does a user customise the version of black that is installed with this approach? In some cases typing_extensions also needs installing for black to work correctly.
There was a problem hiding this comment.
This repo is the formatter, and we always wanted the linter. I have started one.
In rules_lint, the answer is "we don't try to provide the toolchain or the tools, you must provide them".
For example, here's how we get flake8:
https://github.com/aspect-build/rules_lint/blob/main/example/lint.bzl#L18
If a user is formatting code in a certain language, they probably already have the toolchain for that language. It wouldn't be too much effort for them to add three lines to a BUILD file to declare the black binary for us.
This would help with the error above about Go as well. WDYT?
There was a problem hiding this comment.
Okay I'm doing some prototyping over here aspect-build/rules_lint#14
So far it looks promising
There was a problem hiding this comment.
Okay it's more than a prototype. Pretty sure that's the right way to do this with bzlmod, and this repo can just be the WORKSPACE way. Would love your input @agluszak
|
|
||
| python = use_extension("@rules_python//python/extensions:python.bzl", "python") | ||
| python.toolchain( | ||
| is_default = True, |
There was a problem hiding this comment.
I don't think this MODULE file should be setting the default python toolchain?
|
Thanks for the PR that motivated rules_lint! Time to archive this repo. |
Closes #37
TODO:
format/repositories.bzlandnon_module_deps.bzl?