¿Breaking? change in 0.7

[peter-axion]

Per issue #450, 0.7.0 switched NER and REL tasks to use sharding, which changed the signatures of generate_prompts and parse_responses from being a single iterator of text / responses to being an iterator of iterators of docs/responses. Additionally, the tasks had two more fields added (shard_mapper / shard_reducer).

Additionally, and eventually more troublesomely for me, the default shard reducer merges shards using Doc.from_docs(), which fails to merge the doc.metadata field for the different docs and drops it on the ground instead of doing something like taking the first element. So if I pass in a doc with metadata that doesn't need to be sharded, it gets sharded into a single document that still has metadata ([myDoc]), and then gets myDoc2 = Doc.from_docs([myDoc])'d, which makes a myDoc2 without metadata. I have hacked around this by making my keys (term, '._.', 0, None), but that really isn't ideal. Also, for some reason I'm getting stack corruption errors now.

Anyway, v0.7 broke my custom tasks, which were inheriting from those implementations and overloading generate_prompts / parse_responses to support RAG and alternative templates.

I don't know if this counts as a breaking change because maybe I could have written my own task without subclassing existing ones, but the LLMWrapper now passes variables with types to those functions, so I believe it would have been a serious problem even if I had fully implemented my own tasks and not subclassed the existing ones.

[svlandeg]

Thanks for the additional details, @peter-axion! We're currently working towards a v1.0.0 where the APIs should become stable, so it's helpful to understand these use-cases. We'll look into this more - at the very least we probably need to update the 0.0.7 release notes that didn't mention this breaking behaviour. Additionally, it sounds like we need to fix the metadata processing as well.