Migrate toml to be on toml_edit
#340
Comments
|
From comment on #327:
So there will be another crate that does the parsing, which is used by both |
|
|
Thanks for the explanation, though I am a bit worried about the extra compilation time and the increase in binary size caused by this. I just replace toml_edit with toml in cargo-binstall and that removes 3 dependencies while reducing the size of the debug build cargo-bins/cargo-binstall#610 , but if toml is to use toml_edit, I guess it will be no difference from just keep using toml_edit. |
|
We can't say much about either until #327 is complete but once it is, I'd recommend trying it out and reporting back (as new issue) concrete build time and release binary size numbers for us to evaluate if the impact is bad enough and what we can do about it. I say release binary size as that is what I expect most end-users will care about (that is what is generally distributed). If you have a use case for debug binary size, feel free to also share that. |
Sure
TBH, I also don't care about debug binary size much, I just use it to check whether a PR might increase the final release build. |
|
I'd like to join in the conversation by saying that debug builds will matter for constraint machines. It seems that the crate can be made |
The `toml` crate doesn't support TOML 1.0, but `toml_edit` does. While there is a plan to [migrate `toml` to be on `toml_edit`](toml-rs/toml#340), it's not ready yet and it's very easy to switch back to `toml` when it's ready.
|
Once #435 is merged, all of the blockers will be resolved and we can move forward with changing out |
This will help with debugging This only addresses toml-rs#396 for `toml_edit`. The rest won't be addressed until toml-rs#340 is resolved.
|
#457 switched |
This is the other main half of toml-rs#340. Still have deprecations and tests left Note that strings are rendered differently, see toml-rs#287 By extension this also finishes up toml-rs#396. BREAKING CHANGES - `impl Display for toml::Value` now renders as values, not documents, see instead `Table` - `toml::ser::Serializer` only serializes documents, instead see `toml::ser::ValueSerializer` - `toml::ser::tables_last` is removed, no longer needed - `toml::ser::to_vec` is removed to mirror the loss of `from_slice` - atm `toml::ser::to_string_pretty` just causes larger arrays to be indented - `toml::ser::Error` is now opaque - `toml::ser::Serializer::pretty_string` was removed - `toml::ser::Serializer::pretty_string_literal` was removed - `toml::ser::Serializer::pretty_array` was removed - `toml::ser::Serializer::pretty_array_indent` was removed - `toml::ser::Serializer::pretty_array_trailing_comma` was removed - `toml::ser::Serializer` is now used used by value, rather than `&mut` Fixes toml-rs#396
|
#470 takes care of That just leaves
|
This is another example of the benefit of toml-rs#340
tomlwill be a wrapper around thetoml_editcrate, providing serde integration, decoupled from the format-preserving parsing, and offering a more stable APIAs part of switching cargo adopting
toml_edit,toml_edit::easy, a copy oftomls API, was created so cargo could have a single toml parser for both serde and editing.We plan to move
toml_edit::easyinto thetomlcrate, providing nearly the same API at nearly the same performance while reducing overall maintenance effort and allowing people who have both needs to have a common parser.Blockers
toml_editis pretty slow to compile #327Deserializer::endDeserializer::set_require_newline_after_tableDeserializer::set_allow_duplicate_after_longer_tablePerformance
Compatibility
The text was updated successfully, but these errors were encountered: