pkgdev icon indicating copy to clipboard operation
pkgdev copied to clipboard

pkgdev commit: inline array space mangler

Open arthurzam opened this issue 3 years ago • 8 comments

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 )

arthurzam avatar Apr 04 '22 17:04 arthurzam

Note that examples in the bash manual are without spaces:

   Arrays are assigned to using compound assignments of the form
     NAME=(VALUE1 VALUE2 ... )

ulm avatar Apr 05 '22 07:04 ulm

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?

SoapGentoo avatar Apr 05 '22 07:04 SoapGentoo

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?

ulm avatar Apr 05 '22 08:04 ulm

all PYTHON_COMPATs have the same space formatting, we also enforce tabs for indentation, how is that not whitespace micromanagement?

SoapGentoo avatar Apr 05 '22 08:04 SoapGentoo

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?

ulm avatar Apr 05 '22 08:04 ulm

maybe this is a good opportunity to flesh out an actual style guide?

SoapGentoo avatar Apr 05 '22 08:04 SoapGentoo

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.

ulm avatar Apr 05 '22 09:04 ulm

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).

radhermit avatar Apr 05 '22 19:04 radhermit