You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hmm, this [in that PR version] feels rather too magical to me for the interface of this command. In particular, this means that even when you're just trying to write string data, you'll sometimes have it come out as an int or a bool instead, just depending on the data -- depending on exactly what string it was you were trying to store.
Or for another angle on the same thing: this approach would mean that it'd be impossible to store some strings, like "1" or "false".
For example, it'd be impossible to correctly set package.edition in a Cargo.toml file:
$ target/debug/toml set --overwrite Cargo.toml package.edition 2018
$ git diff -U0
diff --git a/Cargo.toml b/Cargo.toml
index 2f232cf98..ac60e2325 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -10 +10 @@ license = "MIT"
-edition = "2018"
+edition = 2018
$ cargo check
error: failed to parse manifest at `/home/greg/w/toml-cli/Cargo.toml`
Caused by:
data did not match any variant of untagged enum MaybeWorkspace for key `package.edition`
… and in a followup comment:
Instead, what would you think about having toml set take a flag to tell it how it should parse the value? Probably "string" would still be the default -- I feel like that's probably the most common.
So e.g.
toml set foo.toml x asdf # a string
toml set foo.toml x --string asdf # the same thing, explicitly
toml set foo.toml x 2018 # still a string: `x = "2018"`
toml set foo.toml x --int 2018 # an int: `x = 2018`
toml set foo.toml x --int asdf # error
toml set foo.toml x --bool false
toml set foo.toml x --bool asdf # error
The text was updated successfully, but these errors were encountered:
Thanks for filing these issues! Added that second comment into the description, and also edited the title to narrow the scope slightly: we might have future issues to add support for setting floats, and datetimes, and even whole tables and arrays (perhaps supplied in JSON form?), but this one can be about just integers and booleans.
Originally posted by @gnprice in #13 (comment):
Hmm, this [in that PR version] feels rather too magical to me for the interface of this command. In particular, this means that even when you're just trying to write string data, you'll sometimes have it come out as an int or a bool instead, just depending on the data -- depending on exactly what string it was you were trying to store.
Or for another angle on the same thing: this approach would mean that it'd be impossible to store some strings, like "1" or "false".
For example, it'd be impossible to correctly set
package.edition
in aCargo.toml
file:… and in a followup comment:
Instead, what would you think about having
toml set
take a flag to tell it how it should parse the value? Probably "string" would still be the default -- I feel like that's probably the most common.So e.g.
The text was updated successfully, but these errors were encountered: