info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Editor extensions to help editing debian/* files?
4 views
Skip to first unread message
Otto Kekäläinen
Jan 21, 2024, 2:50:05 AMJan 21
to
Hi!
What editors and extensions are you using to augment your productivity
and minimize mistakes when editing debian/* files?
I am aware of dpkg-dev-el for Emacs mentioned in the DD reference[1].
I am a big fan of Pulsar[2] and recently found a 'language-debian'
plugin for Pulsar[3], but didn't get it to emit any errors/messages.
I would be interested to learn what editors and integrations others
use specifically for debian/* files. I've witnessed several old DDs
stop their Debian work, and many aspiring ones give up on becoming a
DD, because the Debian packaging work is so laboursome. One small
thing that could ease the burden could be better editor integrations
that help people write and maintain the debian/* files with less
effort.
- Otto
[1] https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html
[2] https://optimizedbyotto.com/post/pulsar-best-text-file-and-code-editor/
[3] https://web.pulsar-edit.dev/packages/language-debian
PS. Related, these are commands I frequently run manually but don't
have any editor integration for:
wrap-and-sort --wrap-always --verbose
make --dry-run --makefile=debian/rules
codespell --write --check-filenames --check-hidden debian/
find debian/ -type f | xargs spellintian --picky
aspell --mode=debctrl -c debian/control
duck -v --color=always
find -name *.pot -exec i18nspector "{}" +; find -name *.po -exec
i18nspector "{}" +;
shellcheck -x --shell=bash $(shell grep -Irnw -e '^#!.*/bash' | sort
-u |cut -d ':' -f 1 | xargs)
shellcheck -x --shell=sh $(shell grep -Irnw -e '^#!.*/sh' | sort -u
|cut -d ':' -f 1 | xargs)
if [ "$(find debian/patches/ -type f -not -name series | wc -l)" !=
"$(wc -l < debian/patches/series)" ]
then
echo "Contents of debian/patches/series does not match number of
patches in debian/patches"
fi
What editors and extensions are you using to augment your productivity
and minimize mistakes when editing debian/* files?
I am aware of dpkg-dev-el for Emacs mentioned in the DD reference[1].
I am a big fan of Pulsar[2] and recently found a 'language-debian'
plugin for Pulsar[3], but didn't get it to emit any errors/messages.
I would be interested to learn what editors and integrations others
use specifically for debian/* files. I've witnessed several old DDs
stop their Debian work, and many aspiring ones give up on becoming a
DD, because the Debian packaging work is so laboursome. One small
thing that could ease the burden could be better editor integrations
that help people write and maintain the debian/* files with less
effort.
- Otto
[1] https://www.debian.org/doc/manuals/developers-reference/developers-reference.en.html
[2] https://optimizedbyotto.com/post/pulsar-best-text-file-and-code-editor/
[3] https://web.pulsar-edit.dev/packages/language-debian
PS. Related, these are commands I frequently run manually but don't
have any editor integration for:
wrap-and-sort --wrap-always --verbose
make --dry-run --makefile=debian/rules
codespell --write --check-filenames --check-hidden debian/
find debian/ -type f | xargs spellintian --picky
aspell --mode=debctrl -c debian/control
duck -v --color=always
find -name *.pot -exec i18nspector "{}" +; find -name *.po -exec
i18nspector "{}" +;
shellcheck -x --shell=bash $(shell grep -Irnw -e '^#!.*/bash' | sort
-u |cut -d ':' -f 1 | xargs)
shellcheck -x --shell=sh $(shell grep -Irnw -e '^#!.*/sh' | sort -u
|cut -d ':' -f 1 | xargs)
if [ "$(find debian/patches/ -type f -not -name series | wc -l)" !=
"$(wc -l < debian/patches/series)" ]
then
echo "Contents of debian/patches/series does not match number of
patches in debian/patches"
fi
Niels Thykier
Jan 21, 2024, 3:50:04 AMJan 21
to
Otto Kekäläinen:
Hi Otto
Personally, I use PyCharm/IDEA with the IDEA-debpkg plugin (the latter I
wrote because there was no existing plugin) or emacs with dpkg-dev-el
depending on the context.
I think my use of PyCharm/IDEA started for similar reasons that you are
praising Pulsar - if I need to work on another file, it would have an
integration for that (like the preview pane with markdown, support for
shellcheck, etc.).
In most cases, PyCharm (and I presume Pulsar as well) has basic
support out of the box or can hint you to a plugin based on the filename
(extension based) - I do not have to hunt it down. Sadly, except for my
own Debian plugin because d/control and d/changelog does not have
extensions... oh well.
Thanks for the command list. I have added a few of them to my todo list
for my plugin. Like `wrap-and-sort` is due now that it supports comments
and has better defaults out of the box.
Btw, `debhelper` has a `dh_assistant` command that can do some very
basic analysis as well. Not sure any of it is useful for editor
integration (especially because some of the features requires that it
receives the same arguments as `dh` or/and `dh_auto_configure`).
Personally, I have used `dh_assistant detect-hook-targets` to detect
which overrides that `dh` would pick up (relies heavily on
"Build-Depends: dh-sequence-foo" style add ons though). Admittedly, not
in an editor context but if you can combine it with something that reads
known make file targets, you could get a "override_typo looks like an
override target but `dh` does not recognize it"-style warning out of it.
Maybe I should just add that feature directly to `dh_assistant`. Then
you can have one more command for your checklist! :D
Best regards,
Niels
> Hi!
>
> What editors and extensions are you using to augment your productivity
> and minimize mistakes when editing debian/* files?
>
> I am aware of dpkg-dev-el for Emacs mentioned in the DD reference[1].
> I am a big fan of Pulsar[2] and recently found a 'language-debian'
> plugin for Pulsar[3], but didn't get it to emit any errors/messages.
>
> I would be interested to learn what editors and integrations others
> use specifically for debian/* files. I've witnessed several old DDs
> stop their Debian work, and many aspiring ones give up on becoming a
> DD, because the Debian packaging work is so laboursome. One small
> thing that could ease the burden could be better editor integrations
> that help people write and maintain the debian/* files with less
> effort.
>
> - Otto
>
> [...]
>
> What editors and extensions are you using to augment your productivity
> and minimize mistakes when editing debian/* files?
>
> I am aware of dpkg-dev-el for Emacs mentioned in the DD reference[1].
> I am a big fan of Pulsar[2] and recently found a 'language-debian'
> plugin for Pulsar[3], but didn't get it to emit any errors/messages.
>
> I would be interested to learn what editors and integrations others
> use specifically for debian/* files. I've witnessed several old DDs
> stop their Debian work, and many aspiring ones give up on becoming a
> DD, because the Debian packaging work is so laboursome. One small
> thing that could ease the burden could be better editor integrations
> that help people write and maintain the debian/* files with less
> effort.
>
> - Otto
>
Hi Otto
Personally, I use PyCharm/IDEA with the IDEA-debpkg plugin (the latter I
wrote because there was no existing plugin) or emacs with dpkg-dev-el
depending on the context.
I think my use of PyCharm/IDEA started for similar reasons that you are
praising Pulsar - if I need to work on another file, it would have an
integration for that (like the preview pane with markdown, support for
shellcheck, etc.).
In most cases, PyCharm (and I presume Pulsar as well) has basic
support out of the box or can hint you to a plugin based on the filename
(extension based) - I do not have to hunt it down. Sadly, except for my
own Debian plugin because d/control and d/changelog does not have
extensions... oh well.
Thanks for the command list. I have added a few of them to my todo list
for my plugin. Like `wrap-and-sort` is due now that it supports comments
and has better defaults out of the box.
Btw, `debhelper` has a `dh_assistant` command that can do some very
basic analysis as well. Not sure any of it is useful for editor
integration (especially because some of the features requires that it
receives the same arguments as `dh` or/and `dh_auto_configure`).
Personally, I have used `dh_assistant detect-hook-targets` to detect
which overrides that `dh` would pick up (relies heavily on
"Build-Depends: dh-sequence-foo" style add ons though). Admittedly, not
in an editor context but if you can combine it with something that reads
known make file targets, you could get a "override_typo looks like an
override target but `dh` does not recognize it"-style warning out of it.
Maybe I should just add that feature directly to `dh_assistant`. Then
you can have one more command for your checklist! :D
Best regards,
Niels
Niels Thykier
Jan 21, 2024, 10:30:04 AMJan 21
to
Niels Thykier:
> [...]
$ apt satisfy 'debhelper (>= 13.11.10), libtext-levenshtein-perl'
$ dh_assistant detect-unknown-hook-targets [--output-format=json]
The code can have false positives - especially if you use `dh ... --with
...`. In that case, you have to pass the same `--with ...` to
`dh_assistant` to avoid the false positive. All the more reason to use
declarative `Build-Depends: dh-sequence-foo`.
For machine output use the JSON format (lintian/lintian-brush, etc.).
The text output is subject to change. MRs for improvements welcome at
https://salsa.debian.org/debian/debhelper/
End sidebar/thread hijack.
Best regards,
Niels
> [...]
>
> Btw, `debhelper` has a `dh_assistant` command that can do some very
> basic analysis as well. Not sure any of it is useful for editor
> integration (especially because some of the features requires that it
> receives the same arguments as `dh` or/and `dh_auto_configure`).
> Personally, I have used `dh_assistant detect-hook-targets` to detect
> which overrides that `dh` would pick up (relies heavily on
> "Build-Depends: dh-sequence-foo" style add ons though). Admittedly, not
> in an editor context but if you can combine it with something that reads
> known make file targets, you could get a "override_typo looks like an
> override target but `dh` does not recognize it"-style warning out of it.
>
> Maybe I should just add that feature directly to `dh_assistant`. Then
> you can have one more command for your checklist! :D
>
> Best regards,
> Niels
>
Ok, added this to debhelper/13.11.10:
> Btw, `debhelper` has a `dh_assistant` command that can do some very
> basic analysis as well. Not sure any of it is useful for editor
> integration (especially because some of the features requires that it
> receives the same arguments as `dh` or/and `dh_auto_configure`).
> Personally, I have used `dh_assistant detect-hook-targets` to detect
> which overrides that `dh` would pick up (relies heavily on
> "Build-Depends: dh-sequence-foo" style add ons though). Admittedly, not
> in an editor context but if you can combine it with something that reads
> known make file targets, you could get a "override_typo looks like an
> override target but `dh` does not recognize it"-style warning out of it.
>
> Maybe I should just add that feature directly to `dh_assistant`. Then
> you can have one more command for your checklist! :D
>
> Best regards,
> Niels
>
$ apt satisfy 'debhelper (>= 13.11.10), libtext-levenshtein-perl'
$ dh_assistant detect-unknown-hook-targets [--output-format=json]
The code can have false positives - especially if you use `dh ... --with
...`. In that case, you have to pass the same `--with ...` to
`dh_assistant` to avoid the false positive. All the more reason to use
declarative `Build-Depends: dh-sequence-foo`.
For machine output use the JSON format (lintian/lintian-brush, etc.).
The text output is subject to change. MRs for improvements welcome at
https://salsa.debian.org/debian/debhelper/
End sidebar/thread hijack.
Best regards,
Niels
Otto Kekäläinen
Jan 21, 2024, 8:20:05 PMJan 21
to
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. 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
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 don't know how much ambition you have for expanding the scope of
dh_assistant. 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
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. 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
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 don't know how much ambition you have for expanding the scope of
dh_assistant. 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
Otto Kekäläinen
Jan 22, 2024, 2:50:04 AMJan 22
to
> 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.
True - LSPs is the common API into linters (and more) nowadays, but I
was ready to settle with something simpler, as building a LSP for
Debian I imagine is a lot of work..
..
> I might have a stab at writing a prototype for a LSP for Debian formats.
..however, if you start doing a minimal prototype it would be a great!
Who knows if the LSP some day in the future would forward snippets to
a Debian-specific LLM that would give hints on what needs to be
changed to conform to the Debian policy :)
> 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.
True - LSPs is the common API into linters (and more) nowadays, but I
was ready to settle with something simpler, as building a LSP for
Debian I imagine is a lot of work..
..
> I might have a stab at writing a prototype for a LSP for Debian formats.
..however, if you start doing a minimal prototype it would be a great!
Who knows if the LSP some day in the future would forward snippets to
a Debian-specific LLM that would give hints on what needs to be
changed to conform to the Debian policy :)
Otto Kekäläinen
Jan 26, 2024, 1:30:04 AMJan 26
to
Hi!
> Thats beginning to look like the history of check-all-the-things.
Yeah, I remember looking into cats some years back as a place to learn
what commands exist. Similarly I also occasionally browse
https://pre-commit.com/hooks.html.
The challenge with having all possible checkers is that they create a
lot of noise and managing the false positives end up being a lot of
work. Not suitable for daily use, but I will probably use cats for
"annual checkups" on stuff I maintain.
It would be nice though if the version in Debian was newer :)
Since https://tracker.debian.org/pkg/check-all-the-things lacks a
working git and homepage link, you guys should probably do a new
upload to Debian.
By the way, I submitted some small fixes at
https://github.com/collab-qa/check-all-the-things/pulls.
> Thats beginning to look like the history of check-all-the-things.
Yeah, I remember looking into cats some years back as a place to learn
what commands exist. Similarly I also occasionally browse
https://pre-commit.com/hooks.html.
The challenge with having all possible checkers is that they create a
lot of noise and managing the false positives end up being a lot of
work. Not suitable for daily use, but I will probably use cats for
"annual checkups" on stuff I maintain.
It would be nice though if the version in Debian was newer :)
Since https://tracker.debian.org/pkg/check-all-the-things lacks a
working git and homepage link, you guys should probably do a new
upload to Debian.
By the way, I submitted some small fixes at
https://github.com/collab-qa/check-all-the-things/pulls.
Otto Kekäläinen
Jan 29, 2024, 1:30:05 AMJan 29
to
Hi!
> > It would be nice though if the version in Debian was newer :)
>
> I probably won't update it until it is suitable for inclusion in a
> stable release. This means at minimum being relatively safe to run in
> an untrusted source tree, probably by using debvm to generate a VM
> containing the relevant tools and running the tools in the VM.
As it happens, I have been writing this tool[1] that runs all builds
and tests inside a container, and check-all-the-things would be a
perfect match to be wrapped by the command 'debcraft validate' that
mounts sources inside a throwaway container.. ;)
https://salsa.debian.org/otto/debcraft
> > It would be nice though if the version in Debian was newer :)
>
> stable release. This means at minimum being relatively safe to run in
> an untrusted source tree, probably by using debvm to generate a VM
> containing the relevant tools and running the tools in the VM.
As it happens, I have been writing this tool[1] that runs all builds
and tests inside a container, and check-all-the-things would be a
perfect match to be wrapped by the command 'debcraft validate' that
mounts sources inside a throwaway container.. ;)
https://salsa.debian.org/otto/debcraft
Johannes Schauer Marin Rodrigues
Jan 29, 2024, 2:00:05 AMJan 29
to
Hi Otto,
Quoting Otto Kekäläinen (2024-01-29 07:06:51)
could you add an entry for your tool as docker solution number twelve to this
table:
https://wiki.debian.org/SystemBuildTools#Package_build_tools
Thanks!
cheers, josch
Quoting Otto Kekäläinen (2024-01-29 07:06:51)
table:
https://wiki.debian.org/SystemBuildTools#Package_build_tools
Thanks!
cheers, josch
Dominique Dumont
Feb 21, 2024, 4:10:06 AMFeb 21
to
On Sunday, 21 January 2024 08:43:05 CET Otto Kekäläinen wrote:
> What editors and extensions are you using to augment your productivity
> and minimize mistakes when editing debian/* files?
That's not exactly an editor extension, but I use 'cme edit dpkg' to modify debian files.
> What editors and extensions are you using to augment your productivity
> and minimize mistakes when editing debian/* files?
This tool provide a GUI with integrated help to edit most debian/* files.
See https://github.com/dod38fr/config-model/wiki/Managing-Debian-packages-with-cme
HTH
0 new messages