abetlen
Implement a flake.nix that uses the upstream llama.cpp flake by reference
Note that this is built on top of #516, which should probably be reviewed first.
This permits llama-cpp-python to be used with the upstream llama.cpp flake.nix deciding how to go about performing the build on the current platform, rather than rebuilding a local copy of libllama with separately-managed build instructions.
To use this, run:
nix develop
and one will be dropped into a shell in which
$ python -c 'import llama_cpp'
functions correctly, without using cmake to build the vendor/llama.cpp source tree (instead, LLAMA_CPP_LIB is set to a /nix/store path containing libllama.dylib or libllama.so built according to the upstream llama.cpp flake.nix file's instructions).
(Notably, this shell will always include a copy of Python 3.10 provided by nixpkgs, independent of whatever operating system Nix is installed on top of; think of Nix as akin to Python's virtualenv mechanism, but applying to software written in languages other than Python, and providing strong guarantees about build idempotence and security -- Nix runs builds in a sandbox with no network access or ability to access files other than explicitly declared dependencies, which is why tools like poetry2nix are necessary)
As a future enhancement, a check should probably be added to ensure that the flake.lock pin and the .gitmodules dependency stay in sync. Adding facilities to permit use without poetry2nix would be another appropriate future extension; likewise, addressing the upstream poetry2nix bug that prevents the server extras from being enabled.
It seems the project has moved on from using poetry, so presumably the flake in the PR will need to be updated to no longer use poetry2nix.
I am interested in this. Would https://nix-community.github.io/pyproject.nix/ be relevant in this context ?
