Implementing a Feast Linter

In the previous blog post, Common Feature Store Workflow with Feast, I gave an overview of how I implemented a workflow for a common feature store using Feast, and gave some ideas as to how the various pieces involving Feast and CI/CD would fit together.

In this post, I want to go into slightly more detail as to how I implemented the Feast linter so that it might give you some ideas of your own. But let’s start with why!

Why Even Bother?

One of the uses of a Linter is to flag stylistic problems, and that’s the main reason why we’re building one. What kind of stylistic problems can come with using Feast?

Feature Versioning

Let’s take feature versioning for example. Now the scheme that we’ve chosen is a simple one: some_feature_v1, some_feature_v2, and so on. Feast doesn’t care how you name your feature views, just as long as there are no name collisions. But your team should care about proper naming conventions if it cares about code maintainability!

There’s actually a pretty cool use case for naming your features with a_vN prefix. You can technically list all the features with some_feature as the prefix and sort the features and voilà, you can easily build a report or UI with all versions of a some_feature. I haven’t implemented this yet but it’s…