Add chromem-go

[philippgille]

Hi 👋 ,

I'd like to add chromem-go to this list. I added it to the AI section because it doesn't serve as a general database (different from all entries in the database section), and as a vector store its main purpose is storing embeddings (generated with LLMs) and retrieving them based on cosine similarity. It's used in Retrieval-Augmented Generation (RAG) pipelines, where the next step is to feed the fetched documents to an LLM. (See project README and examples). Also it integrates with Ollama which is in the AI section. It's already listed on the Ollama README here.

Regarding coverage, I haven't integrated Codecov in this repo yet, but there are various unit tests:

$ go test -cover ./...
ok  	github.com/philippgille/chromem-go	0.008s	coverage: 64.6% of statements

Let me know if that's a blocker and if having a Codecov step in CI would unblock this.

We want to ensure high quality of the packages. Make sure that you've checked the boxes below before sending a pull request.

• I have read the Contribution Guidelines
• I have read the Maintainers Note
• I have read the Quality Standards

Not every repository (project) will require every option, but most projects should. Check the Contribution Guidelines for details.

• The repo documentation has a pkg.go.dev link.
• The repo documentation has a coverage service link.
• The repo documentation has a goreportcard link.
• The repo has a version-numbered release and a go.mod file.
• The repo has a continuous integration process that automatically runs tests that must pass before new pull requests are merged.
• Continuous integration is used to attempt to catch issues prior to releasing this package to end-users.

Please provide some links to your package to ease the review

• forge link (github.com, gitlab.com, etc): https://github.com/philippgille/chromem-go
• pkg.go.dev: https://pkg.go.dev/github.com/philippgille/chromem-go
• goreportcard.com: https://goreportcard.com/report/github.com/philippgille/chromem-go
• coverage service link (codecov, coveralls, etc.):

Pull Request content

• The package has been added to the list in alphabetical order.
• The package has an appropriate description with correct grammar.
• As far as I know, the package has not been listed here before.

Category quality

Note that new categories can be added only when there are 3 packages or more.

Packages added a long time ago might not meet the current guidelines anymore. It would be very helpful if you could check 3-5 packages above and below your submission to ensure that they also still meet the Quality Standards.

Please delete one of the following lines:

• The packages around my addition still meet the Quality Standards.

Thanks for your PR, you're awesome! 😎

[github-actions]

Thank you for contributing to awesome-go. We will review your contribution as soon as possible.

Make sure you add the links in the body of the pull request that are requested in the contribution guide:

• repo link
• pkg.go.dev
• goreportcard.com
• coverage

Your project is under review. It may take a few days to be approved.

[yassinebenaid]

Generally speaking, LGTM.

However, regarding your note:

Let me know if that's a blocker and if having a Codecov step in CI would unblock this.

Having codecov (or similar) is always good. And when looking at the CI run. The coverage report is missing.
This makes it hard to get an idea about the coverage.

-   go test -v -race ./...
+   go test -v -race -cover ./...

Also, regarding your coverage example:

$ go test -cover ./...
ok  	github.com/philippgille/chromem-go	0.008s	coverage: 64.6% of statements

The contributing guide suggests to have at least >=80% of test coverage for non-data-related projects. and >=90% for data-related projects.

if the library/program is testable, then coverage should be >= 80% for non-data-related packages and >=90% for data-related packages. (Note: the tests will be reviewed too. We will check your coverage manually if your package's coverage is just a benchmark result);

@phanirithvij Thoughts ?.

[phanirithvij]

Yes, please track the coverage in some form, not necessarily using a particular service like codecov. And try to improve the coverage, and if is not possible due to some technical reasons let us know.

It is very highly recommended to have a stable or reaching stable i.e. v1.0.0 to get accepted in awesome-go but the README warns it is beta. If you have a specific date or timeline in mind on when your stable release will be then you can resubmit. If you agree with this close this PR and when you create a new one cc me and @yassinebenaid