Updating `nixpkgs` ?

[drupol]

Hello,

I'm reaching out to kindly inquire about the rationale behind creating an external flake, given that there's an existing upstream version in nixpkgs, outdated sure, but existing. I'm genuinely curious to understand the challenges or considerations that might have led to the decision to maintain a separate version rather than contributing your changes back to nixpkgs.

Please know that my intention is purely to understand the situation better and to explore how I might help backporting your changes in nixpkgs.

Thanks!

[abysssol]

There wasn't much "rationale" per se, but there are two main reasons that I didn't try to contribute to nixpkgs. First, perhaps more understandably, I don't have any experience contributing code, and in particular I am unfamiliar with how nixpkgs is structured and what the process for contributing to it would be like, so I never really considered contributing to "the" nixpkgs as an option. Second, I am a lurker online. I don't use social media, post to forums, or in any other way actively interact with other people; hell, I don't even rate youtube videos. I am only used to passively consuming what other people have made, so the idea of working on something so public is a little intimidating. Responding to these two issues on this repo is the first time in years that I've conversed with someone online. In short, lack of experience/familiarity/understanding/knowledge/comfort/confidence.

So, when I tried using ollama but realized it was too out of date to use a model I wanted, since my habit is to keep to myself and not interact with others, a flake was the obvious solution; a flake is self-contained, and doesn't require integration with existing code, nor interaction with other people. For the first flake version (tag 0.0.0, for ollama 0.1.17), I mostly just copied the existing package in nixpkgs (for ollama 0.1.7) with updated sources and minor modifications. The ollama build architecture at that time hadn't changed much from what was already in nixpkgs, so it was relatively easy. I never expected anyone other than myself to ever use the flake, or even see it. The readme was just me practicing writing documentation, not intended to actually be read by anyone; I was basically just pretending to be a real programmer.

After using ollama for a little, I lost interest and promptly forgot about the flake's existence. The flake's more recent update (tag 1.1.0) to support ollama 0.1.23 only happened because of this issue. Ollama's build process had changed quite a bit by that point, so that update was far more involved and more difficult than the first version of the flake was. But after messing around with ollama's build scripts and figuring out what dependencies were required, I finally got it to work (though I'm still not convinced cuda is working correctly).

Also, might as well respond to your other comment while I'm at it.

Dear @abysssol,

Do you have plan to merge your flake in nixpkgs, it would be amazing to have it.

I didn't have any such plans, but if you want me to, I'm willing to try. Since I'm unfamiliar with contributing in general and nixpkgs specifically, I'll probably need some guidance, and I might end up failing/giving up, but I'll give it a shot.

[drupol]

Hello again,

First and foremost, I want to express my sincerest appreciation for taking the time to share your thoughts and experiences with me. It's truly inspiring to hear about your journey, from your initial hesitations to your eventual success with creating a flake. Your candidness and the details of your journey are genuinely appreciated.

I completely understand how the idea of contributing to a project as huge as nixpkgs can seem daunting, especially when you're stepping out of a comfort zone of solitude online. Your reasons resonate with many who find the threshold of contributing to open-source projects intimidating at first. However, I want to assure you that the nixpkgs community is incredibly welcoming and supportive of newcomers, regardless of their experience level. My open-source time is mostly dedicated to review first contributors pull requests and make them succeed.

The process of contributing can indeed seem complex, but you're not alone in this journey. Many of us, including myself, are here to guide you through every step, from understanding the structure and submission process to providing feedback and assistance with any challenges you might encounter. Your contributions, such as the flake you've created, are valuable and have the potential to benefit many within the community. What you've achieved on your own is commendable and reflects a level of skill and dedication that we highly appreciate in nixpkgs.

Seeing your willingness to consider contributing despite your reservations is incredibly motivating. I believe that with a little guidance, you can make significant contributions. We all start somewhere, and every contribution, no matter its size, helps improve the project for everyone, at a world scale.

If you're open to it, I'd be more than happy to personally guide you through the process of contributing to nixpkgs. There's no pressure to get everything perfect on the first try, and there's plenty of room for learning and growth. Remember, every expert was once a beginner, and the open-source community thrives on collaboration and the diverse perspectives that each contributor brings.

Please let me know if you're interested in taking this step. I'm here to support you, answer any questions you might have, and make your transition into contributing as smooth as possible. Whether it's technical guidance, moral support, or just a chat about nixpkgs, I'm available.

Looking forward to hearing from you and, hopefully, collaborating together on making nixpkgs even better.

Regards

PS: I've never rated any youtube videos either :D

[abysssol]

If you're open to it, I'd be more than happy to personally guide you through the process of contributing to nixpkgs.

Please let me know if you're interested in taking this step.

Thank you for being so supportive. Yes, I'm definitely interested in learning to contribute to nixpkgs, and I would really appreciate your help along the way. I'll probably start by reading the contributing guide and the pkgs readme, and I'll consult with you if I have any questions. I do already have one question; are these github issues the preferred place to talk, or are there any other platforms that are better? Maybe along the lines of zulip? I heard it's working well for rust development.

Also, you should be aware that this flake does not currently support darwin. It would be difficult for me to add support for it, since I need to build on darwin for testing, but I do not own any apple products (nor do I particularly want any). The only possibility I can think of is a darwin virtual machine; I'll have to look into that.

I should also let you know that I may not always be able to communicate at expected times. I have free running/non-24-hour sleep, so I won't always be awake when you are. As I write this, I'm ready to go to sleep, and I will right after sending this. In another couple months though, I may be just waking up at this time. Sorry for any inconvenience this may cause.

[drupol]

Thank you for being so supportive. Yes, I'm definitely interested in learning to contribute to nixpkgs, and I would really appreciate your help along the way. I'll probably start by reading the contributing guide and the pkgs readme, and I'll consult with you if I have any questions. I do already have one question; are these github issues the preferred place to talk, or are there any other platforms that are better? Maybe along the lines of zulip? I heard it's working well for rust development.

Thank you for your enthusiasm and willingness to contribute to nixpkgs! It's great to hear that you're ready to embark on this journey, and I'm here to support you every step of the way. Starting with the contributing guide and the pkgs readme is an excellent first step. Please don't hesitate to reach out if you have any questions or need clarification on anything.

Regarding communication, our community primarily uses GitHub for tracking issues and contributions. For more immediate or real-time discussions, we've found Matrix to be an effective platform. It offers a good balance for both asynchronous and near-real-time conversations, which seems to align well with your schedule given your unique sleep pattern. Please, feel no pressure regarding timely responses; we fully understand and respect everyone's personal circumstances and time zones.

Here are a few tips to get you started:

1. Take a look at how ollama is packaged in nixpkgs and compare it with your flake. This will give you a good sense of how to structure your contribution.
2. Fork nixpkgs on your own GitHub account to start experimenting.
3. Create a branch for your work, ideally named in a way that reflects the contribution you're making, like ollama/bump/0.1.24 for example.
4. Work in your branch, commit, push, let the CI test your changes

Also, you should be aware that this flake does not currently support darwin.

It's completely okay if your flake doesn't currently support Darwin. We has a robust continuous integration system that checks your contributions against the most common architectures, including Darwin. If there are any compilation issues on Darwin, we have a knowledgeable group specifically for Darwin-related concerns who can assist.

I should also let you know that I may not always be able to communicate at expected times. I have free running/non-24-hour sleep, so I won't always be awake when you are. As I write this, I'm ready to go to sleep, and I will right after sending this. In another couple months though, I may be just waking up at this time. Sorry for any inconvenience this may cause.

Open-source projects thrive on contributions from diverse schedules and time zones, making asynchronous communication methods like GitHub issues and PRs preferred. This approach accommodates contributors' varied schedules, ensuring that open-source remains a stress-free and enjoyable endeavor for everyone involved. While we don't expect immediate responses, a gentle nudge might be sent after a few days just to check in, but always with understanding and flexibility.

Thank you once again for stepping forward. I look forward to seeing your contributions and am here to assist with any questions or guidance you might need along the way.

Be careful to one thing, contributing to open-source might be addictive, once you start contributing to one package, you'll have a better understanding of the whole process, and you'll most probably want to contribute more, which is totally fine, but always with moderation ;)

[abysssol]

Would it be better to build for cpu by default and let rocm or cuda be enabled by override (or some other method?), or should they be enabled by default?

Also, do you know of any function like the update operator // or lib.attrs.recursiveUpdate that concatenates lists contained in the set? I've looked around for it, but I couldn't find it.

[drupol]

Would it be better to build for cpu by default and let rocm or cuda be enabled by override (or some other method?), or should they be enabled by default?

Yes, that's what I would do.

Also, do you know of any function like the update operator // or lib.attrs.recursiveUpdate that concatenates lists contained in the set? I've looked around for it, but I couldn't find it.

Nope, maybe you'll find what you're looking for on https://noogle.dev/ ?

[abysssol]

Yes, that's what I would do.

Sorry, that's too ambiguous for me to understand whether you meant gpu enabled or disabled by default. Could you please specify?

Also, thanks for showing me noogle, I somehow never discovered it til now.

[drupol]

Oops sorry 😔

I would build it by default with CPU support, then, switch from one version to another using a simple parameter flag.

[abysssol]

I've prepared the branch updating ollama here. I plan to open a pull request sometime tomorrow. I would appreciate it if you could take a quick look at it to see if anything bad jumps out at you (commit messages, commit size/chunking, code or formatting, etc), so I can fix them before opening the pull request.

Do you know if it's possible to get nix to cache binaries with alternate flags enabled, so gpu support doesn't need to be rebuilt on every user's machine? Such as in pkgs.ollama.override { enableRocm = true; }.

Also, is @drupol:matrix.org the correct name of your matrix account? I created a matrix account @abysssol:tchncs.de, and wanted to add you there for miscellaneous communication.

[drupol]

I've prepared the branch updating ollama here. I plan to open a pull request sometime tomorrow. I would appreciate it if you could take a quick look at it to see if anything bad jumps out at you (commit messages, commit size/chunking, code or formatting, etc), so I can fix them before opening the pull request.

I had a quick look at it, and it seems totally fine. Since I'm quite new in the Nix world, I would definitely suggest opening a pull request against NixOS/nixpkgs so we can also have feedback from other and more knowledgeable maintainers. Making reviews on PR is also easier since we can add inline code comments.

Do you know if it's possible to get nix to cache binaries with alternate flags enabled, so gpu support doesn't need to be rebuilt on every user's machine? Such as in pkgs.ollama.override { enableRocm = true; }.

That's a good question, and I'm currently unable to reply to it, maybe this is something to be discussed in the PR itself, with some other people.

Also, is @drupol:matrix.org the correct name of your matrix account? I created a matrix account @abysssol:tchncs.de, and wanted to add you there for miscellaneous communication.

Yes, I just sent you a message.

Have a good day!

[abysssol]

I sent this pull request to update ollama in upstream nixpkgs.