Get rid of (serde_)y(a)ml

[nc7s]

serde_yaml is unmaintained, so trippy switched to the serde_yml fork, but it has a worrying code quality (hardcoding c_char as i8). YAML is a confusing format to begin with. So, it'd be nice if we could switch to TOML, which is already a dependency. Currently (almost) all usage of YAML is in test data. For example,

trippy/crates/trippy-core/tests/resources/state/nat.yaml

Lines 1 to 22 in e2c7726

	largest_ttl: 3
	rounds:
	- probes:
	- 1 C 333 10.1.0.1 0 12340 80 43012 43012
	- 2 C 777 10.1.0.2 1 12340 80 20544 20544
	- 3 C 778 10.1.0.3 2 12340 80 20544 20544
	- probes:
	- 1 C 123 10.1.0.1 3 12340 80 43012 43012
	- 2 C 788 10.1.0.2 4 12340 80 20544 20544
	- 3 C 789 10.1.0.3 5 12340 80 20544 20544
	- probes:
	- 1 C 123 10.1.0.1 6 12340 80 43012 43012
	- 2 C 780 10.1.0.2 7 12340 80 20544 20544
	- 3 C 781 10.1.0.3 8 12340 80 20544 20544
	expected:
	hops:
	- ttl: 1
	last_nat_status: no_nat
	- ttl: 2
	last_nat_status: nat
	- ttl: 3
	last_nat_status: no_nat

This could be translated to:

largest_ttl = 3

[[rounds]]
probes = [
  "1 C 333 10.1.0.1 0 12340 80 43012 43012",
  "2 C 777 10.1.0.2 1 12340 80 20544 20544",
  "3 C 778 10.1.0.3 2 12340 80 20544 20544"
]

[[rounds]]
probes = [
  "1 C 123 10.1.0.1 3 12340 80 43012 43012",
  "2 C 788 10.1.0.2 4 12340 80 20544 20544",
  "3 C 789 10.1.0.3 5 12340 80 20544 20544"
]

[[rounds]]
probes = [
  "1 C 123 10.1.0.1 6 12340 80 43012 43012",
  "2 C 780 10.1.0.2 7 12340 80 20544 20544",
  "3 C 781 10.1.0.3 8 12340 80 20544 20544"
]

[[expected.hops]]
ttl = 1
last_nat_status = "no_nat"

[[expected.hops]]
ttl = 2
last_nat_status = "nat"

[[expected.hops]]
ttl = 3
last_nat_status = "no_nat"

Some files use the tag feature of YAML e.g. !SingleHost, which presumably could be replaced with an optional key in TOML and some processing in the code.

The usage other than "almost all" is in i18n strings, introduced by rust-i18n, which is not packaged in Debian and "polyfilled" with an ad-hoc patch to deliver the new functionality ASAP without seeing rust-i18n packages through NEW queue. Arguably, it could be replaced with i18n-embed, which supports the Fluent translation system, as well as the old gettext system, both very popular and widely supported. It has built-in locale resolution through the locale_config crate. But this is probably too big a change, and a too abrupt one shortly after i18n is released.

Note this is strongly influenced by my PoV as a downstream package maintainer, focusing on maintainability (serde_yml) and avoiding unnecessary dependencies (serde_yml, rust-i18n), which are not always the biggest concerns for upstream developers.

I'm willing to implement the change if either is considered acceptable.

[fujiapple852]

Hi again @nc7s,

trippy switched to the serde_yml fork, but it has a worrying code quality. YAML is a confusing format to begin with. So, it'd be nice if we could switch to TOML

I agree with your concern about serde_yml and also the suggestion to replace yaml with toml throughout.

Some files use the tag feature of YAML e.g. !SingleHost, which presumably could be replaced with an optional key in TOML and some processing in the code.

Yes, I don't see that as being a major issue moving to toml as I have full control over both the file format and code and there are no backward compatibility concerns as these are only used for internal CI testing.

The usage other than "almost all" is in i18n strings, introduced by rust-i18n, which is not packaged in Debian and "polyfilled" with an ad-hoc patch to deliver the new functionality ASAP without seeing rust-i18n packages through NEW queue.

I'm not overly fond of the current rust-i18n crate, it was the "least worst" option I found when researching at the time. I would quite like to move to something better, provided it is cross platform and works standalone (i.e. does not make any assumption about other packages installed on the system). Fluent sounds like a good format (I especially like the 3rd party collaborative editing tools) and i18n-embed seems solid, i'd be fine with trying that.

I'm also tempted to just do something akin to your patch, as doing this translation is simple enough that pulling in dependencies may be overkill.

But this is probably too big a change, and a too abrupt one shortly after i18n is released.

The changes would all be internal implementation details so i'm fine with it. Having said that, the current crate does seem to support toml as well, so perhaps that is the easiest option for now?

Note this is strongly influenced by my PoV as a downstream package maintainer, focusing on maintainability (serde_yml) and avoiding unnecessary dependencies (serde_yml, rust-i18n), which are not always the biggest concerns for upstream developers.

I'm keen to do whatever I can to make it easier for downstream package maintainers, it is very much in my interest as well. I'm super impressed with your extensive efforts to patch it for Debian, kudos.

I'm willing to implement the change if either is considered acceptable.

Thank you. To be clear, i'm also fine to do this work as it is something I wanted to do anyway, however if you want to do it then i'd gladly accept a PR.