Otto Kekäläinen:
Hi!
Thanks for the tip, Niels!
It would be cool if dh_assistant had some kind of generic command like
"dh_assistant validate" which would attempt to introspect all
information silently and emit output only if it fails to parse
something.
That might be an option. The question is what more would you expect here
that is actually feasible to implement. :)
Feel free to propose concrete ideas and I will have a look at them.
Sadly, debhelper was never designed to be introspect-able, but depending
on the ask it might be doable or doable with some limitations.
Additionally it could emit a non-zero exit code on errors.
I tested your latest command and it works as you expected, though it
does not use exit code.
> # dh_assistant detect-unknown-hook-targets
The hook target override_dh_car_configure in debian/rules does not
seem to match any known commands.
# echo $?
0
Adding an exit 2 as a "linter" exit code in the next version with a
"--no-linter-exit-code" (open for better names) to have it always return
0 (which I suspect will be easier for some users).
Also if the JSON included the filename and line number of the finding
it would be handy:
{
"unknown-hook-targets": [
{
"candidates": [],
"filename": "debian/rules",
"target-name": "override_dh_car_configure"
}
]
}
I would be happy to include that. Unfortunately, I only have the
information available from:
LC_ALL=C make -Rrnpsf debian/rules debhelper-fail-me 2>/dev/null
Which seems to have the following limitations:
* filename/line is *not* included for "empty" targets
* When a line number is present, it is for the first line of the recipe
and not the target definition itself. One might be tempted to do
(lineno - 1) but it is not accurate[0].
I am open to suggestions for this that does not involve parsing the
makefile itself. I will leave ad-hoc parsing of Turing complete
languages to other programs.
I don't know how much ambition you have for expanding the scope of
dh_assistant.
The dh_assistant tool is growing organically based on requests, or
things I need, or when I notice people needing to introspect something
and I can easily provide it via dh_assistant. :)
I did not aim for it to be a full-fledged linter, though I do not mind
adding debhelper related linting where possible.
We already have Lintian which has a massive amount of
checks, including ones related to debian/rules. It is just a pity
Lintian does not support checking a single file or the debian/
directory contents without building the package.. [1]
[1] https://bugs.debian.org/262783
The infrastructure and design choices of lintian is working against
lintian here. I doubt #262783 will ever be solved as there is a major
difference between a 'clean assembled packages' and the '"mess" you call
a git checkout".
Even if we get #262783, a lot of lintian checks are written to check
.deb packages because that is the final result and you avoid a lot of
"what if d/rules decided to do X - what if it does *not* do X"
ambiguity. Which the person who does #262783 would probably also spend a
lot of effort porting binary checks in to the ("dirty") source context
where you have less context.
I looked into better tooling/editor support in general for Debian
languages in general. I think the industry answer is that "someone"
ought to build a "language (LSP) server" for the Debian languages, which
would enable editors with LSP support[1] to get the same basic features.
Among features that LSP servers can provide are:
* Configurable on save actions (such as wrap-and-sort)
* Format file on user request (wrap-and-sort, again)
* Diagnostics (linting)
* Text highlighting / inline documentation / inlay hints
* Auto-completion
The first half is basically what you are looking for and the latter half
is what I have been focusing on in my plugin, so it does seem to cover
our interests.
I might have a stab at writing a prototype for a LSP for Debian formats.
But it will not be in `dh_assistant`.
Best regards,
Niels
--
[0]: Sample makefile
"""
my-target:
# Some makefile level comment (not indented)
first line of the target definition
"""
Here the line number reported by make would be 3, but the target
definition is actually line 1 (so doing a -1 would be "off by one per
line of comment")
[1]: Which allegedly includes:
* emacs via eglot (?), which comes built-in these days
* neovim
* atom/pulsar via plugin (?)
* IDEA via open source plugin or builtin via their paid subscription
