Provide Qdrant via JLL? (lazily?)

[bdklahn]

Hello,
Kaimon.jl looks really cool! Thanks for creating this. I think it opens possibilities which I don't think many fully grasp, yet!

A while back, I threw this thing up on Yggdrasil.
https://github.com/JuliaPackaging/Yggdrasil/blob/master/Q/Qdrant/build_tarballs.jl
(I'm not affiliated with Qdrant; just though it was a good implementation)

It is kinda quick 'n dirty/lazy, because I maybe could/should actually do the/a Rust build, rather than simply pull the precompiled upstream binaries. Also, it kinda requires any updater to grab the new upstream hashes, etc., rather than maybe just being able to update the version string.

I just wondered if that could be useful to be able to dynamically pull Qdrant . . . maybe lazily, on first use.

I had meant to engage the upstream Qdrant folks, to see if they'd have any interest in maintaining that build_tarballs.jl file. For them, it could be a(n alternative) binary source. I just haven't had time.

Thanks

[kahliburke]

@bdklahn Thanks for the feedback. Hmm it's an interesting idea, although it's also really simple to run the docker container. So I wonder if this path might add more complexity than it's solving? The docker container is maintained and is documented as the recommended installation path.

So, I have mixed feelings about this approach. Did you find installing and running through docker to be too cumbersome?

[bdklahn]

I guess I was considering this as a way to add less complexity for users. I'm a software engineer with a lot of sysadmin experience. So I, myself, have no problem installing and running Docker, or Podman, or Apptainer, etc. I know how they work and have used and modified them a lot.
But requiring users to run two separate extra services to get the most benefit out of a package . . .

I'm not 100% sure why/how the Qdrant folks are using Docker. Sometimes people use it to bootstrap pods for scalable services (E.g. with Kubernetes, etc.), for their paid hosted services. Some use it to mitigate their glibc deps not always matching hosts. But, theoretically, they could be doing static musl for glibc and making their Rust binary very portable (not needing any chroot "containment" work around).

BinaryBuilder is a way to get something which works and is published in an easy way to leverage Julia Pkg Artifacts as a separate "module" (package).

I work with software developers, engineers, domain experts, and "users". All of them would prefer anything outside their scope of interest to be more "declarative" vs. "imperative".

] add ThisPackage
vs.
Adding a bunch of documentation lines to say . . .
Go figure out how to . . .
Install Docker (Desktop)
Start some daemon
Run (pull) a container.
Install Ollama
etc.

Idk . . . Re: containers: sometimes it feels a bit overkill to stack a bunch binary blobs into an overlay filesystem (or flatten into a squashfs), and then run a VM on non-native systems, just to run a single server binary.

Sometimes that is the best/only thing you can do. But I think things like the Julia Artifacts system and BinaryBuilder at least offer the possibility of not having to brute force it like that.

But maybe I'm missing something. I thought the Rust toolchain was capable of creating portable binaries. Did Qdrant not do that?

[kahliburke]

@bdklahn, yeah I don't know the full story, I'm just working off of their docs:

https://qdrant.tech/documentation/quickstart/#how-to-get-started-with-qdrant-locally

This just recommends running via docker. I'm game to try an alternative method, in the end all Kaimon cares about is an API to call at a known port. Currently it's actually hardcoded to 6333 which is the default. Alternative paths to this end are welcome. Do you want to take a stab at a PR?