-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build(nix): Package gguf-py #5664
Conversation
7efb80d
to
1d0a97c
Compare
This PR is good for review for the standalone packaging of
Open to other ideas. |
.devops/nix/package-gguf-py.nix
Outdated
{ | ||
lib, | ||
llamaVersion, | ||
python3, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
buildPythonPackage
, poetry-core
, numpy
as arguments. No need for python3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The evaluating scope should set them explicitly then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if there's a cleaner way: 00fbda0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the scope inherits from python3Packages
, which in turn inherits from pkgs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, sorry, mistake on my part. This one only inherits from pkgs
, we need to handle python separately.
EDIT: this is good, we'll see about making one for python, and making it easy to reuse in pythonPackagesExtensions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, then we're good to go for this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If by "good to go" you mean we need to move the python scripts out of the main derivation so that it doesn't depend on the choice of python version 😅
EDIT: I phrased this badly. What I meant is, I think the way to introduce support for the python scripts is to separate the python and C++ parts and to add means to extend python3Packages
. I'm pretty exhausted today and won't be able to make my explanation any better, but I'll try to send some code tomorrow. I do acknowledge that we shouldn't extend the scope of the PR too much and you likely want this feature merged in a timely manner, etc, etc, but right now I think there's a bit more work to be done
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem. I gave splitting the Python/C++ devShells and derivation a shot. I don't think it addresses extending python3Packages, but it should address the other concern about the mixed-in Python and C++ derivation, and get the python scripts exposed with .#python-scripts
. Please take a look and tell me what you think, then maybe we can get the python3Packages
thing done and get this in :D
4957125
to
00fbda0
Compare
28d0c6d
to
ad57699
Compare
5ab8e9c
to
cbd8200
Compare
cbd8200
to
0a82d07
Compare
Rebased to after merge of #5745. Commits will need to be cleaned up, but this is open for review otherwise. |
54ce50d
to
5493dd8
Compare
7729067
to
0188318
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to work for my workflow with nix develop .#default-extra
. Thanks!
I've tested running pyright
on the whole repository (which requires access to all python libraries used within), and it works without problem.
I've also tested building a -DGGML_VULKAN=TRUE
build with nix develop .#vulkan-extra
, and it works too.
There are more things in the $PATH
(because python libraries only were added to the python interpreter before, not also the $PATH
), but I think this might be useful in some situations.
Rebuilding gguf-py
at each change might be cumbersome, though, but I think this is better than before because I simply never tested building gguf-py
with poetry before, but with this it's now handled when creating a devShell. (I never needed to actually build the package because convert_hf_to_gguf.py
uses some other trick anyway to include the local gguf-py
instead of the package)
I think I like this.
Nix has an older version
- Filter out non-source files from llama-scripts flake derivation - Clean up unused closure - Remove scripts devShell
e61d467
to
bd574ba
Compare
Rebased to master. @ggerganov this should be ready for merge. cc @SomeoneSerge |
Thanks for merging! |
llamaVersion ? "0.0.0", | ||
}: | ||
|
||
let | ||
pythonPackages = python3.pkgs; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A note for the future: I'd discourage using python3.pkgs
in favour of python3Packages
because the former does not support splicing. We're not using any cross-compilation in this flake, but I think it's important to stay minimal and idiomatic so as not to spread confusion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's good to know. This should be changed to use python3Packages next time someone visits these files.
buildPythonPackage = pythonPackages.buildPythonPackage; | ||
numpy = pythonPackages.numpy; | ||
tqdm = pythonPackages.tqdm; | ||
sentencepiece = pythonPackages.sentencepiece; | ||
pyyaml = pythonPackages.pyyaml; | ||
poetry-core = pythonPackages.poetry-core; | ||
pytestCheckHook = pythonPackages.pytestCheckHook; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
None of this would be necessary if we made a subscope for python packages, but this can be left for future. And the UX for implementing that currently sucks anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes would be sure nice to have a python scope at some point, this is rather ugly.
* style: format with nixfmt/rfc101-style * build(nix): Package gguf-py * build(nix): Refactor to new scope for gguf-py * build(nix): Exclude gguf-py from devShells * build(nix): Refactor gguf-py derivation to take in exact deps * build(nix): Enable pytestCheckHook and pythonImportsCheck for gguf-py * build(python): Package python scripts with pyproject.toml * chore: Cleanup * dev(nix): Break up python/C devShells * build(python): Relax pytorch version constraint Nix has an older version * chore: Move cmake to nativeBuildInputs for devShell * fmt: Reconcile formatting with rebase * style: nix fmt * cleanup: Remove unncessary __init__.py * chore: Suggestions from review - Filter out non-source files from llama-scripts flake derivation - Clean up unused closure - Remove scripts devShell * revert: Bad changes * dev: Simplify devShells, restore the -extra devShell * build(nix): Add pyyaml for gguf-py * chore: Remove some unused bindings * dev: Add tiktoken to -extra devShells
* style: format with nixfmt/rfc101-style * build(nix): Package gguf-py * build(nix): Refactor to new scope for gguf-py * build(nix): Exclude gguf-py from devShells * build(nix): Refactor gguf-py derivation to take in exact deps * build(nix): Enable pytestCheckHook and pythonImportsCheck for gguf-py * build(python): Package python scripts with pyproject.toml * chore: Cleanup * dev(nix): Break up python/C devShells * build(python): Relax pytorch version constraint Nix has an older version * chore: Move cmake to nativeBuildInputs for devShell * fmt: Reconcile formatting with rebase * style: nix fmt * cleanup: Remove unncessary __init__.py * chore: Suggestions from review - Filter out non-source files from llama-scripts flake derivation - Clean up unused closure - Remove scripts devShell * revert: Bad changes * dev: Simplify devShells, restore the -extra devShell * build(nix): Add pyyaml for gguf-py * chore: Remove some unused bindings * dev: Add tiktoken to -extra devShells
* style: format with nixfmt/rfc101-style * build(nix): Package gguf-py * build(nix): Refactor to new scope for gguf-py * build(nix): Exclude gguf-py from devShells * build(nix): Refactor gguf-py derivation to take in exact deps * build(nix): Enable pytestCheckHook and pythonImportsCheck for gguf-py * build(python): Package python scripts with pyproject.toml * chore: Cleanup * dev(nix): Break up python/C devShells * build(python): Relax pytorch version constraint Nix has an older version * chore: Move cmake to nativeBuildInputs for devShell * fmt: Reconcile formatting with rebase * style: nix fmt * cleanup: Remove unncessary __init__.py * chore: Suggestions from review - Filter out non-source files from llama-scripts flake derivation - Clean up unused closure - Remove scripts devShell * revert: Bad changes * dev: Simplify devShells, restore the -extra devShell * build(nix): Add pyyaml for gguf-py * chore: Remove some unused bindings * dev: Add tiktoken to -extra devShells
What and why
Currently, the Nix build does not ship with the
gguf-py
lib, rendering scripts likeconvert-hf-to-gguf
unusable.This is an attempt to package
gguf-py
withbuildPythonPackage
. Very barebones at the moment and needs some work to exclude the Nix builtgguf
from the devShells, and some thought into other things like packaging the heavier python dependencies (we don't want them to be included by default, but we need a way to opt-in).CC: @SomeoneSerge