Fork me on GitHub
#clj-yaml
<
2022-09-18
>
slipset06:09:50

Hey, first of all, thanks for all the help and activity on this! I would like to provide a little bit of confusing, much likely contradicting, and probably useless perspective: 1. I think the main problem is to fix the weird octal thingy that snakeyaml broke for us, because it seems to break our users. 2. I don’t think that anyone has started to depend on 1) and even if so, I’d be happy to break them if that leads to clearer/easier code for us 3. I don’t think it’s super wise to expose the underlying lib (snakeyaml) because that would put us in a world of pain should we decide to switch it out 4. I would not be interested in evolving clj-yaml much, as none of us seem to like YAML, and clj-yaml has served many well for a long time (this contradicts 3 in a way) 5. These are like, just my opinions, man, so please feel free to disagree and disregard.

👍 3
borkdude10:09:02

I agree with @slipset - 1 + 2) we should fix the breaking change problem (somehow) 3) I agree, but also think it will be too risky to silently swap out the implementation, there will be unforeseen breakages. Unless we call it a breaking change release, which might be ok. So let's limit the exposure to implementation details. 4. Agreed. I think this library should be developed in a "let's minimize suffering for all living beings, especially clojure developers, but let's not invest too much energy into it" fashion

borkdude10:09:45

If we reach a conclusion on the above, I think we should document these decisions so we can fall back on those when more issues arise

3
lread16:09:34

Thanks for the thoughts! For 3) Agree with you both. Let's be wary of exposing innards. And yeah swapping out the underlying yaml lib would be breaking in behaviour but the API might be able to stay the same.

👍 1
lread16:09:54

I find this YAML world feels a bit wheel-spinny.

lread16:09:35

If we were to someday support YAML 1.2 would we also still want to be able to handle YAML 1.1? What makes sense in the world-of-YAML?

borkdude16:09:46

no, YAML 1.1 and YAML 1.2 are incompatible

borkdude16:09:02

since they have different notations for octal numbers

borkdude16:09:24

and probably for other reasons too

lread16:09:43

Does a YAML 1.2 file typically indicate that it is a YAML 1.2 file?

lread16:09:13

I do see some https://yaml.org/ support both YAML 1.1 an 1.2. But that might be kinda like a lib, to exaggerate, supporting both json and xml? Bit of a mess, yah? I'm just curious at this point and do agree with @slipset's point number 4.

slipset16:09:40

So given the above, I’d suggest keeping clj-yaml at 1.1 and perhaps let Someone Else(TM) do another lib for 1.2?

borkdude16:09:35

yes, stay at clj-yaml 1.1, maybe convince snakeyaml to revert the stupid octal thing or do it ourselves and support the thing grzm wanted (ignore unresolved tags)

borkdude16:09:56

with minimal efforts

borkdude16:09:00

YAML isn't worth our time

💯 1
lread16:09:10

Yes, this clj-yaml ramp-up has been majorly distracting me from other more interesting distractions. simple_smile But it has been interesting to learn more about this little thorn of a format.