Simplified nix flake for build, dev shell, and cached build

[ProjectInitiative]

I see #60. Honestly not sure which method is better at the moment. This PR allows local building with nix build and a development shell with nix develop. Ideally adding an entry to nixpkgs might solve #60 and #32 since it will be built into the eco-system. Open to discussion. Still learning nix myself.

[SilasMarvin]

This is a really awesome pr! I've used nix a little bit but not enough to know the proper ways to do things. Ss there some kind of way to make sure this builds correctly in our CI?

[SilasMarvin]

Is this going to try to build it with llama.cpp support? I don't think we want that by default. The default features are what we should have built by default.

[ProjectInitiative]

I will be tweaking somethings and posting an update. This was a hacky way of going about it. I am updating another PR to a nixpkgs submission that is more idiomatic and will try to update this flake accordingly :)

[SilasMarvin]

Sounds good

[ProjectInitiative]

removed a bunch of unnecessary components and did some refactoring

[ProjectInitiative]

This is the main package. Essentially when running nix build locally, the default entry is the starting point. The devPackage and devShells are more of conveniences for being dropped into a shell with all needed dependencies, but still track a cached build at /tmp/.cargo so during the dev cycle, one can run cargo commands as they please with the necessary caches.

[ProjectInitiative]

doCheck = false;
Disables all testing. See nixpkgs implementation to see how to disable individual tests. As this nix flake is most likely not going to be integrated into any CI, I think it is okay to disable them for now since the goal is just for folks who want to pull and have a dev env/build from source avenue. Suggestions welcome.

[ProjectInitiative]

This is a really awesome pr! I've used nix a little bit but not enough to know the proper ways to do things. Ss there some kind of way to make sure this builds correctly in our CI?

I am not sure I understand: Is there a desire to use nix instead for CI? As these changes aren't necessary or intended to replace a working CI, unless it's needed.

[mergemoveagree]

Hey! Love to see work on packaging lsp-ai for nixpkgs! I currently am using my own local package (https://github.com/mergemoveagree/nixos-configuration/tree/d9baa33e94b2680957defcc776704e4443266417/pkgs/lsp-ai) that was initialized with nix-init. While I am also relatively new to nix, I've combed through a mountain of different package flakes to try and find idiomatic styling.

Here are some differences between our flakes that I think would be beneficial to add:

• use outputHashes rather than allowBuiltinFetchGit -- the hashes are in my "callBuilder.nix" file so you could just copy them from there
• include a "default.nix" generated by flake-compat for the folks who don't want to switch to nixos-unstable just yet
• Consider moving the package into an overlay -- I see this in a lot of other flakes for big projects

I'm not the most knowledgeable, but I'm happy to try and answer any questions or help research things we both know!

[ProjectInitiative]

Currently working through the nixpkg approval process. It is involved to say the least. I think there might be a difference between the two goals. I mainly just created this flake as a semi easy way to setup a dev environment. I definitely think it can be improved based on the feedback from the nixpkg review process. I think a solution lies somewhere in-between what you have and what I posted

[mergemoveagree]

This is a really awesome pr! I've used nix a little bit but not enough to know the proper ways to do things. Ss there some kind of way to make sure this builds correctly in our CI?

I am not sure I understand: Is there a desire to use nix instead for CI? As these changes aren't necessary or intended to replace a working CI, unless it's needed.

I think he's referring to ensuring that the nix package builds (which theoretically could fail even if the rust package can compile via the normal imperative commands). There seems to be some documentation already over using nix in CI, and if there are no immediate plans to merge into the nixpkgs repo (updated based on latest comment), there's an official tutorial on using GitHub Actions to automatically push binaries to a Cachix binary cache (to prevent everyone building the same derivation on their own systems) if this project were to adopt one.

[SilasMarvin]

This is a really awesome pr! I've used nix a little bit but not enough to know the proper ways to do things. Ss there some kind of way to make sure this builds correctly in our CI?

I am not sure I understand: Is there a desire to use nix instead for CI? As these changes aren't necessary or intended to replace a working CI, unless it's needed.

I think he's referring to ensuring that the nix package builds (which theoretically could fail even if the rust package can compile via the normal imperative commands). There seems to be some documentation already over using nix in CI, and if there are no immediate plans to merge into the nixpkgs repo (updated based on latest comment), there's an official tutorial on using GitHub Actions to automatically push binaries to a Cachix binary cache (to prevent everyone building the same derivation on their own systems) if this project were to adopt one.

That is exactly what I am referring to. I'm a bit worried to merge this in without actually using nix myself and having no way to verify that it is consistently working. I know a lot of people do use it and I would love to have a flake, but I want to make sure it is sustainable.

[mergemoveagree]

That is exactly what I am referring to. I'm a bit worried to merge this in without actually using nix myself and having no way to verify that it is consistently working. I know a lot of people do use it and I would love to have a flake, but I want to make sure it is sustainable.

Since I've set up my flake to be mainly for package distribution and this PR set this up to be for the devShell, I could make make a PR to this PR (or directly contribute, whatever is preferred) with parts of my lsp-ai flake and also a GitHub Actions CI for building the nix package if @ProjectInitiative is open to working together!

[peperunas]

Chiming here to show interest.

Any updates on this? @ProjectInitiative @mergemoveagree

[SilasMarvin]

If we get something tested and working for a few people I'm happy to merge it in! I'm not very experienced with writing my own flakes though so heavily relying on everyones thoughts here.

[peperunas]

Update on my side - my bad, actually - that lsp-ai has been merged into nixpkgs so I guess this PR is obsolete.

[ProjectInitiative]

It isn't obsolete necessary, there might be a desire from a dev perspective to have a nix-ified dev shell. From a consumer environment, yes, the nixpkg version (slightly different to conform to nixpkg standards) is gtg for consumers of the package. I haven't had a ton of time to test this specifically since I haven't needed to contribute to the project codebase directly.