On the future of our nixpkgs fork

[VlinkZ]

I’m also in complete agreement with this post. As I mentioned before:

@VlinkZ

• Create a new repo that depends on nixpkgs as a flake input and work towards migrating everything into the new repo (or set of repos) to the point that we can drop the nixpkgs dependence

[I] feel [this] option may be more manageable as it allows us to slowly ramp up to maintaining our set of packages instead of maintaining 80000+ right at the start

As linked by @getchoo, I’ve been working on splitting stdenv from the rest of nixpkgs as a base for our core repo. This may take a little bit longer, but in the meantime it is completely feasible to start building using core’s nixpkgs export understanding that switching over to using core exclusively may require additional effort.

I think that by starting small and not burdening ourselves with all of nixpkgs, we can all focus our efforts on creating a better package structure rather than getting crushed under the weight of nixpkgs.

@srxl

I’d honestly go as far as to say that the “soft fork” phase of the roadmap should be entirely scrapped, and we should instead focus on building the hard fork.

I agree 100%, given the current situation, I think a soft fork would just hinder further development.

@Nairou

Could even do something like AUR in Arch, where the entirety of nixpkgs is in a “community” repo; not a lot of maintenance, but it can be used if what you need isn’t available yet in the aux repos.

I also believe that in the time being, even once we have a functioning fully aux system, having a nixpkgs export from core may be a good idea (although using flakes a user could just add the input themselves).

Finally I agree that the roadmap itself needs to be seriously reevaluated. I feel like as some time has passed, the original roadmap does not reflect the reality of the direction of this project. Some part I think are no longer valid:

• Soft Fork: I believe that trying to maintain a soft fork currently is a bad idea as outlined above
• Fork CppNix: I think given the recent unveiling of Lix, the Cli SIG should discuss what the plan should be moving forward
• Infrastructure: If we go in the direction proposed and build up our package set gradually rather than by forking nixpkgs, I believe that work on infrastructure such as CI and a binary cache can start a lot sooner given the smaller scale

As of right now, I agree with @getchoo’s plan of actions, with the addition that infrastructure work start in parallel with work on core and SIG repos.