Ragna AWS extension package

[pmeier]

I recently got access to AWS Bedrock and decided to build the first (that I know of) Ragna extension package with it: https://github.com/pmeier/ragna-aws. This implements a superset of #173. Feel free to comment here or open issues on the repo directly if you have any questions.

[nenb]

Nice example! What do you think about creating some sort of monorepo for storing all the ragna extensions? So, each extension would be it's own package, but all extensions would be stored in the same repo? Comes with the usual monorepo benefits, and it makes 'discovery' of the extensions really easy.

Coincidentally, I spent a bit of time yesterday seeing how easy it would be to add support for other 'filesystems' via fsspec (see #202). I'll share the work at some point today, but most of the challenge I had was getting everything to play nicely with the REST API and the UI.

Does ragna-aws integrate with the REST API and/or UI?

[pmeier]

What do you think about creating some sort of monorepo for storing all the ragna extensions? So, each extension would be it's own package, but all extensions would be stored in the same repo? Comes with the usual monorepo benefits, and it makes 'discovery' of the extensions really easy.

I don't like it, for one major reason: who is in charge of the mono repo? Imagine I am and you want to add something that I disagree with. What now? If you are unable to add your patch to the central extension repo, the only choice you have is to create an external one. And now we are back at the starting point of how are we discovering these "second class extensions".

My idea is to have a "How to extend Ragna" tutorial in the documentation that links to a third-party packages page. On there we can just advertise stuff and people can send PRs to add their package to the list. I don't think that is much different than having a monorepo in terms of discoverability.

I'll share the work at some point today, but most of the challenge I had was getting everything to play nicely with the REST API and the UI.

Feel free to share any pain points so we can have a look if there is something we can improve.

Does ragna-aws integrate with the REST API and/or UI?

Yes. The assistants don't need any extra treatment and the S3 document is something that I have used before so it works as well.

[pmeier]

Re discoverability: pytest has a plugin page as part of their documentation: https://docs.pytest.org/en/7.1.x/reference/plugin_list.html. Granted, the have auto discovery from PyPI, but I feels something similar would be a good thing for us.

We are also thinking about creating an GH organization for Ragna. That could also be an umbrella for extensions. The lifecycle would be for users to create an external package and if it becomes popular there is an option to upstream it to the Ragna organization without losing any permissions on the actual repository.

[nenb]

That's all fine! There is nothing stopping individuals (ie me!) creating their own monorepo with extensions if they want to, and this is probably the more practical approach as you outlined. (And any extensions I might contribute, happy to merge these into an 'offical' repo if and when that time happens.)

[nenb]

Feel free to share any pain points so we can have a look if there is something we can improve.

In case you have time now, I have just pushed my changes for the Python & REST APIs here - see the new notebooks in examples for some description of how to use it.

I will push the UI and markdown parser later this evening. I probably spent most of the time with the UI, but to be fair this is probably a bit separate to the core ragna functionality (although I agree that it's an essential component).

The changes I made were largely me just playing around. Feel free to ignore all of it! The motivation I had was that I personally didn't really like having to retrieve files to my local system, then upload to the server (and if I have understood correctly, the S3 extension also requires file upload, but to S3). I wanted to be able to read files from remote filesystems directly from the server. If you think this might be useful, happy to chat how I can help contribute to the work.

[nenb]

I won't open an issue for now (that includes the related material in #202), but if it's of interest, I will open an issue later for 'filesystem' support.

[pmeier]

Just as FYI: I only have time to look at this next week. But will do so.

[pmeier]

@nenb could you open a PR from your branch? That would help me see the aggregated diff compared to our main as well as persists all of the discussion on the Ragna repository.

[nenb]

I just realised I never pushed the UI and markdown parser last. 😬 I'll push the UI to the same branch now. I won't push the markdown parser as it seems like I never finished it (and I vaguely remember this distracting me last week, which is probably why I forgot to commit the UI changes).

The UI was a bit fiddly, and so I didn't put too much time into it. The basic idea was that a user would supply a GitHub path and some file formats in the UI, click the 'Add' button to generate the metadata, and then click the 'Start Conversation' button to compute the embeddings (screenshot attached). Let me know if any of this is of interest, and happy to adapt as necessary.