Flexibility vs. Rigidity in marvin

[pietz]

Hey team,

I love the approach of marvin but I've been thinking about its current methodology of having multiple/many ways of doing the same thing. I can extract data with a function, by extending the BaseModel or by using a decorator.

Flexibility is great when it's needed. More flexibility will lead to confusion for newcomers.

I want to start a discussion of what users think of this and how the devs approach it. For example I think having marvin.extract and marvin.model potentially makes sense. If you want/can to change the code of the actual model, the marvin.Model results in cleaner code. Otherwise the function does well. But having both the decorator and the model doesn't make sense to me. Maybe I'm missing a use case. Getting rid of one might make marvin more concise.

[zzstoatzz]

hi @pietz - we really like the new utils like extract and cast, and (not to speak for everyone) even generally prefer them to the old abstractions like @ai_model because they're more explicit.

in fact, model is now just a specific use of cast that we primarily have for backwards compatibility. I'm not sure that the omission of previous components like model would trim down marvin as a library in a meaningful way

In short, i think we prefer our utils (e.g. cast extract) at this point, but want to maintain backwards compat for those familiar so we're accepting multiple ways to do the same thing for now.