cargo add: Nicer TOML Files
#15
Comments
|
+1 to this. Running using |
|
another annoyance:
we should really parse this into an extensive AST and operate on that level instead of using hashmaps without stylistic and meta information. i didn’t need that yet, but i can also imagine a complex |
|
Like @rgardner mentioned in #57, there was some effort by @vosen to implement some of this in toml-rs/toml-rs#64. It might be a good idea to use that code as a starting point for a new crate that parses toml into an AST that maintains more stylistic information but that also offers a "high level" interface that can be used like a nested hashmap to easily insert/update values. |
|
toml-rs was written when the rust ecosystem wasn’t as far so maybe someone would have fun just implementing a new TOML parser in nom or peresil or so. toml-rs is fine for reading TOML, but not for editing it. |
|
Good idea, @flying-sheep. There are always people asking for suggestions on what to implement to learn Rust. A TOML parser that can write nice files is probably both easy to start and enough of a challenge to spend some time with. I think I'm going to post this in a few places 😄 |
|
yup, toml is really easy to parse. no whitespace, no ambiguities. therefore no state and no backtracking. whatever you choose (parser combinator or classic tokenizer + AST parser), it shouldn’t be much of a problem |
|
Hi guys. This discussion got a little bit fragmented. I've summed up the current state of toml-rs/toml-rs#64 on Discourse (tl;dr It's not dead). But I think this place is slightly more fitting for planning what to actually do. Since my goal is the same as yours (having TOML parsing that doesn't mangle |
|
tomllib (I renamed toml_parser) is out now at version 0.1.1. It is currently limited to parsing documents, getting values, setting/changing values and getting subkeys of a key. This should be enough to get cargo-bump and the |
|
That sounds awesome, @joelself! I'll have a look at tomllib (← cool name, btw) when I'm home next week. Maybe I'll even have some time to help out! 😃 |
|
I would still like to see this happen someday... |
181: Start world domination r=killercup a=ordian cc #15, #69. This is an experiment with [toml_edit](https://github.com/ordian/toml_edit) to figure out what the right API (LeopoldArkham/Molten#8, cc @LeopoldArkham) is for the upcoming integration with Molten, but also can be useful by itself while Molten is not yet ready. Basically, all we need is an `Item`, which can represent anything (`None`, `Table`, `InlineTable`, `String`, ...), `IndexMut<&str, Output=Item>` implementation for Item and a bunch of downcasting methods (`is_table`, `as_table`, ...). Deleting an item is just replacing it with `None`.
|
I think the three checkboxes can be ticked, but cargo-edit still adds double-quoted version specifiers to my single-quoted .toml files. Should I file a new issue and let this be closed or wat do? 😄 |
|
@flying-sheep best you open a new one for that! |
|
@flying-sheep feel free to open an issue for respecting single-quoted style. |
|
I did! #217 |
|
It seems that cargo upgrade still removes some comments, e.g. in this file the commant of a specific package was removed [dependencies]
# very useful comment remains
wasm-bindgen = "0.2.80" # very useful comment REMOVED!!!Is there a way for the upgrade to just change the version number and leave everything as is? |
|
Just double checked that |
A comment on killercup/cargo-edit#15 had me worried that `cargo add` was deleting comments now. It appears that isn't the case for inline tables. Standard tables however do delete comments. The work to make sure they don't conflicts with another need. When changing the source, we delete the old source fields and append the new which can cause some formatting to be carried over unnecessarily. For example, what would normally look like ```toml cargo-list-test-fixture-dependency = { optional = true, path = "../dependency", version = "0.0.0" } ``` When fixed to preserve comments with my naive solution looks like ```toml cargo-list-test-fixture-dependency = { optional = true , path = "../dependency", version = "0.0.0" } ``` Note that `optional = true` used to be last, so space separating it and `}` was kept, now separating it and `,`. More work will be needed to get this into an ideal state but we can at least have confidence with inline tables for now.
test(add): Ensure comments are preserved A comment on killercup/cargo-edit#15 had me worried that `cargo add` was deleting comments now. It appears that isn't the case for inline tables. Standard tables however do delete comments. The work to make sure they don't conflicts with another need. When changing the source, we delete the old source fields and append the new which can cause some formatting to be carried over unnecessarily. For example, what would normally look like ```toml cargo-list-test-fixture-dependency = { optional = true, path = "../dependency", version = "0.0.0" } ``` When fixed to preserve comments with my naive solution looks like ```toml cargo-list-test-fixture-dependency = { optional = true , path = "../dependency", version = "0.0.0" } ``` Note that `optional = true` used to be last, so space separating it and `}` was kept, now separating it and `,`. More work will be needed to get this into an ideal state but we can at least have confidence with inline tables for now.
A comment on killercup/cargo-edit#15 had me worried that `cargo add` was deleting comments now. It appears that isn't the case for inline tables. Standard tables however do delete comments. The work to make sure they don't conflicts with another need. When changing the source, we delete the old source fields and append the new which can cause some formatting to be carried over unnecessarily. For example, what would normally look like ```toml cargo-list-test-fixture-dependency = { optional = true, path = "../dependency", version = "0.0.0" } ``` When fixed to preserve comments with my naive solution looks like ```toml cargo-list-test-fixture-dependency = { optional = true , path = "../dependency", version = "0.0.0" } ``` Note that `optional = true` used to be last, so space separating it and `}` was kept, now separating it and `,`. More work will be needed to get this into an ideal state but we can at least have confidence with inline tables for now.
A comment on killercup/cargo-edit#15 had me worried that `cargo add` was deleting comments now. It appears that isn't the case for inline tables. Standard tables however do delete comments. The work to make sure they don't conflicts with another need. When changing the source, we delete the old source fields and append the new which can cause some formatting to be carried over unnecessarily. For example, what would normally look like ```toml cargo-list-test-fixture-dependency = { optional = true, path = "../dependency", version = "0.0.0" } ``` When fixed to preserve comments with my naive solution looks like ```toml cargo-list-test-fixture-dependency = { optional = true , path = "../dependency", version = "0.0.0" } ``` Note that `optional = true` used to be last, so space separating it and `}` was kept, now separating it and `,`. More work will be needed to get this into an ideal state but we can at least have confidence with inline tables for now.
Cargo.tomlstructure too much, e.g. keep the orderingclippy = {version = "0.0.19", optional = true}The text was updated successfully, but these errors were encountered: