New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keywords mode broken for complex keys that happen to contain /
#64
Comments
Interesting! Thanks for reporting @bshepherdson! |
ResearchI had a look around at what other libraries do here.
Here are some initial ideas: Option 1: Do nothing.Let the people suffer! 😈 Option 2: Silently do not convert a YAML key to a Clojure keyword when the resulting keyword would be unreadable.We do this for some cases now, anything that returns nil for user=> (keyword 45)
nil Option 3: Throw when the conversion from YAML key to Clojure keyword results in an unreadable keyword.This is a variant of Option 2. Option 4: Introduce a
|
I'm away today but will take a look tomorrow |
I prefer option 4. Roundtripping JSON <-> EDN with keywords is a known problem when keys contain spaces, etc. I would not put any efforts in trying to "do the right thing" but leave this right thing to the user. I prefer the name |
Thanks @borkdude, sounds good to me. I'll follow up with a PR that also updates docs to promote usage of Note clj-yaml docs state:
I feel this is a bit of an unfortunate inherited design choice. I would have preferred that this behaviour be off by default. |
I like |
The parse-string and parse-stream function now accept new :key-fn option. See docs and docstrings for details. Closes clj-commons#64
The parse-string and parse-stream function now accept new :key-fn option. See docs and docstrings for details. Also: - docs: move the note on keyword args outside of parsing Closes #64
This logic https://github.com/clj-commons/clj-yaml/blob/master/src/clojure/clj_yaml/core.clj#L144 uses
(or (keyword k) k)
to try to parse map keys when thekeywords
setting is true.Unfortunately
clojure.core/keyword
is a bit too forgiving, and parses some things that it probably shouldn't. My map has JSON strings as keys, and some of the parts of those keys have/
in them, which results in this:Since there are unmatched quotes and so on in there, the resulting EDN is mangled - doesn't
(read-string (pr-str x))
properly anymore.which has unbalanced
{}
s because the second{
is quoted but there are three real}}}
at the end.A stricter condition for what makes a valid keyword is needed. I've worked around this with the regex
#"^[0-9a-zA-Z_/\.\-]+$"
for my own purposes; that may not be quite general enough.The text was updated successfully, but these errors were encountered: