4 ms·

Show HN: A Language Server Implementation for SystemD Unit Files

78 points by arandomhuman 1y ago

A Language Server Protocol (LSP) implementation for systemd unit files, providing editing support with syntax highlighting, diagnostics, autocompletion, and documentation made with rust.

andy_nguyen 1y ago
[flagged]
- arandomhuman 1y ago
  I think a user of _not_ neovim they'd have to implement their own js client. I honestly can't say much but with INI style formatting it's been mostly based on contstants rather than abstract syntax tree parsing which is unique and a bit of a problem in its own right. I haven't implemented a language server before so this was a learning experience, but I was very pleasantly surprised how adding it to my neovim configuration was. I am hoping at some point it's added to "mason" so it's even easier. I would create a vscode client, but I am not really very familiar with that ecosystem. Welcoming anyone to implement this in any other editors. This is just the language server implementation with no assumption regarding clients.
  - do_not_redeem 1y ago
    I regret to inform you--you just responded to an LLM bot.
    - arandomhuman 1y ago
      it's that bad these days? Yikes :( I will not be redeeming.
Splizard 1y ago
This is great! There's way too many arcane text file formats (configs, Dockerfiles, workflow definitions etc) without any sort of fast feedback loop on type-safety, documentation etc. We need more projects like this and if a system is running SystemD, this needs to be enabled and integrated with any LSP-supported editors.
- arandomhuman 1y ago
  Thanks for the positive feedback! The documentation needs a bit of revision, but I agree there's a lot of configuration file formats that should be supported with language servers that might not necessarily have rich AST parsing as part of their contents.
rendaw 1y ago
I made a Systemd competitor/aternative https://github.com/andrewbaxter/puteron https://github.com/andrewbaxter/puteron that uses JSON for everything. The advantage to JSON is you can use a `$schema` key at the top and vscode will do autocompletion, error checking, and (I think) documentation from the jsonschema automatically without needing a custom language server. The power of standards at work! I was trying to figure out why Systemd decided on their ini-like syntax instead of something like xml or json or whatever. I thought maybe it was some standard that existed at the time, but it does seem to be a custom format unique to systemd...
- arandomhuman 1y ago
  That’s very interesting, but systemd is pretty pervasive I really don’t think it’s going anywhere anytime soon for better or for worse. Language servers aren't just adopted in vscode, other editors use them in fact. I am not a VS Code user myself, but I appreciate their implementation of the language server protocol, they did a fantastic job with that.
  - rendaw 1y ago
    Yeah sorry, I didn't mean to imply that. Having a language server for systemd is great, I hate having to look things up and I fully expect to still be writing systemd unit files in the forseeable future... Thanks for this!
- hamandcheese 1y ago
  I was not involved in the decision, but my guess is: - xml is too verbose - yaml is too complex + suffers some notable ambiguity issues - json isn't very human friendly (no comments) - a lot of other linux software uses ini-style configs
  - mrweasel 1y ago
    Maybe also to add to that: If you start having things like arrays and dictionaries available, people will start using them in their configuration and then configuration starts becoming an issue. I don't think I've seen a product where the configuration is in YAML or JSON, where the configuration files haven't grown into a confusing mess.
figmert 1y ago
Would be good to add support for custom units based on generates (e.g. Podman[0]). [0] https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
- arandomhuman 1y ago
  thanks, not familiar with this in all entirety, will keep this in mind and always welcome for contributions expanding functionality :)
mgartin 1y ago
This is great, I will definitely try it out in emacs. We use systemd unit files for quite a few things. During holidays I'm planning to uprade my setup to use more lsp and llm! Thanks!
purevpnpartners 1y ago
this is great.

78 points by arandomhuman 1y ago

A Language Server Protocol (LSP) implementation for systemd unit files, providing editing support with syntax highlighting, diagnostics, autocompletion, and documentation made with rust.

andy_nguyen 1y ago

[flagged]

arandomhuman 1y ago
I think a user of _not_ neovim they'd have to implement their own js client. I honestly can't say much but with INI style formatting it's been mostly based on contstants rather than abstract syntax tree parsing which is unique and a bit of a problem in its own right. I haven't implemented a language server before so this was a learning experience, but I was very pleasantly surprised how adding it to my neovim configuration was. I am hoping at some point it's added to "mason" so it's even easier. I would create a vscode client, but I am not really very familiar with that ecosystem. Welcoming anyone to implement this in any other editors. This is just the language server implementation with no assumption regarding clients.
- do_not_redeem 1y ago
  I regret to inform you--you just responded to an LLM bot.
  - arandomhuman 1y ago
    it's that bad these days? Yikes :( I will not be redeeming.

Splizard 1y ago

This is great! There's way too many arcane text file formats (configs, Dockerfiles, workflow definitions etc) without any sort of fast feedback loop on type-safety, documentation etc. We need more projects like this and if a system is running SystemD, this needs to be enabled and integrated with any LSP-supported editors.

arandomhuman 1y ago
Thanks for the positive feedback! The documentation needs a bit of revision, but I agree there's a lot of configuration file formats that should be supported with language servers that might not necessarily have rich AST parsing as part of their contents.

rendaw 1y ago

I made a Systemd competitor/aternative https://github.com/andrewbaxter/puteron https://github.com/andrewbaxter/puteron that uses JSON for everything. The advantage to JSON is you can use a `$schema` key at the top and vscode will do autocompletion, error checking, and (I think) documentation from the jsonschema automatically without needing a custom language server. The power of standards at work! I was trying to figure out why Systemd decided on their ini-like syntax instead of something like xml or json or whatever. I thought maybe it was some standard that existed at the time, but it does seem to be a custom format unique to systemd...

arandomhuman 1y ago
That’s very interesting, but systemd is pretty pervasive I really don’t think it’s going anywhere anytime soon for better or for worse. Language servers aren't just adopted in vscode, other editors use them in fact. I am not a VS Code user myself, but I appreciate their implementation of the language server protocol, they did a fantastic job with that.
- rendaw 1y ago
  Yeah sorry, I didn't mean to imply that. Having a language server for systemd is great, I hate having to look things up and I fully expect to still be writing systemd unit files in the forseeable future... Thanks for this!
hamandcheese 1y ago
I was not involved in the decision, but my guess is: - xml is too verbose - yaml is too complex + suffers some notable ambiguity issues - json isn't very human friendly (no comments) - a lot of other linux software uses ini-style configs
- mrweasel 1y ago
  Maybe also to add to that: If you start having things like arrays and dictionaries available, people will start using them in their configuration and then configuration starts becoming an issue. I don't think I've seen a product where the configuration is in YAML or JSON, where the configuration files haven't grown into a confusing mess.

figmert 1y ago

Would be good to add support for custom units based on generates (e.g. Podman[0]). [0] https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html https://docs.podman.io/en/latest/markdown/podman-systemd.uni...

arandomhuman 1y ago
thanks, not familiar with this in all entirety, will keep this in mind and always welcome for contributions expanding functionality :)

mgartin 1y ago

This is great, I will definitely try it out in emacs. We use systemd unit files for quite a few things. During holidays I'm planning to uprade my setup to use more lsp and llm! Thanks!

purevpnpartners 1y ago

this is great.