pkgdev commit: inline array space mangler
Add a simple mangler that works only on simple inline arrays, that are set into a environment variable, to auto add spaces after and before the circled brackets.
Meaning a line like: DOCS=(README.md example.txt)
Will mangle into DOCS=( README.md example.txt )
Note that examples in the bash manual are without spaces:
Arrays are assigned to using compound assignments of the form
NAME=(VALUE1 VALUE2 ... )
The bash manual also defines functions as
fname () compound-command [ redirections ]
(with the space between the name and parentheses), in fact the environment file is like that too. Your point?
So if we omit the space in function definitions, then maybe we should omit it in array assignments as well, for consistency? :smile:
But seriously, my point is that there's nothing wrong with omitting the spaces, and all of the following are fine:
DOCS=(README.md example.txt)
DOCS=( README.md example.txt )
DOCS=(
README.md
example.txt
)
What would be the point of whitespace micro-management here? Does it improve readability, or what?
all PYTHON_COMPATs have the same space formatting, we also enforce tabs for indentation, how is that not whitespace micromanagement?
For example, we have things like local mycmakeargs=() or DOCS=() for assignment of an empty array all over the place. These would be required to be written with a space then?
maybe this is a good opportunity to flesh out an actual style guide?
Yes, that's where to start. Then, maybe pkgcheck should warn. But IMHO a tool like pkgdev should be very conservative about changing the files that are committed.
Just my opinion, if Gentoo wants to continue down the path of mangling various bash constructs then it needs something like a bash style guide (copy from some other existing one?), checking for bash style issues (either in pkgcheck or using something like shellcheck) as part of the standard dev flow, and actually using a bash parser.
Doing this in a hacky fashion using regular expressions or similar with no overarching linting support is ill-advised.
How I'd do it (which is also a ton of work and is why I never worked on it in the pkgcore stack) is have a separate library for bash parsing (tree-sitter gets most of the way there) that also allows for mangling the AST in defined ways based off various style choices and then serializing the AST back into raw code (tree-sitter won't help you here last I checked). Then that library can be leveraged by both pkgcheck and pkgdev for linting or mangling as wanted.
In essence, this would entail creating a tool like gofmt or rustfmt for bash of which there exist several options but none work well enough or support all that was mentioned above last I checked (most lack hooks into parsing for linting support or use sub-standard parsing designs).