Make models less strict about atproto HOT 4 CLOSED

I can only speak in general terms as someone trying to learn ATProto who is using your library as a tool to do this and hasn't yet released anything but may do so shortly.

Since ATProto is still evolving I need the tool to evolve with it. I don't consider anything I write to be something that can be forgotten and expected to work if ATProto changes. Any process that can be done to gracefully manage changes so there is less breakage would be great but not too much at the expense of your time as the developer of the library. If I have to code extra steps now to facilitate this process and know there will eventually be a one time change (?) when ATProto is finalized that's fine by me.

from atproto.

new note. if we allow extra fields it will not help to detect such bugs of bsky #205. probably that's why this bug wasn't reported because they ignore "detailed" fields. and our SDK helps the third time to bsky team to fix bugs related to lexicon

from atproto.

Lexicons are allowed to change over time, within some bounds to ensure both forwards and backwards compatibility. The basic principle is that all old data must still be valid under the updated Lexicon, and new data must be valid under the old Lexicon.

• Any new fields must be optional
• Non-optional fields can not be removed.
• Types can not change
• Fields can not be renamed

From here: https://atproto.com/specs/lexicon#lexicon-evolution

the first item confirms that we should make extra fields optional; the other 3 items confirm that other strict checks must be still enabled

from atproto.

Okay, I decided to do it. #207 brings:

• Allowing additional fields with access to it
• Warn on found additional field(s) with explanation why it could happen
• Ability to disable warn via env var (for now, maybe in the code later)
• Unit tests that cover lexicon evolution from official docs. tests
• DotDict is only for unknown record types now

what is not included: access to extra fields using snake case (protocol uses camelCase)

upd. warns have been disabled because it gives false positives due to the way pydantic works

from atproto.