Nixpkgs being a monorepo has some serious advantages, like the ability of finding absolutely anything with a simple grep. The repo is also not that big of a monorepo, so you don’t need special tool to clone and check it out.
That said, several components could definitely split out and use separate issue trackers, NixOS for once, without major disadvanteges. However, I wouldn’t recomment that unless we get flakes stabilised, because the current composability of Nix repositories is pretty bad.
The solutions to social problems aren’t technical, they’re social. I don’t think splitting up the monorepo is the answer there (though maybe its a good idea for other reasons), because people just avoiding each other by not having to interact often won’t solve this problem.
Very much disagree. These two go hand in hand. So much of what we do is technological solutions to social problems.
There is nothing in Flakes that helps with this, it’s an orthogonal problem. Overlays are kind of working, but they don’t compose that well. The module system would work, but is too slow on that scale.
I said composing but I was thinking more of the hassle that is managing multiple sources of Nix packages with channels or using fetchTarball; not composing packages sets.
AFAIK, flakes should solve this by proving a way of specifying inputs to your configuration and commands to easily pin and update them.
Also neatly solved by any other pinning tool like npins, niv or gridlock, there’s nothing exclusive about Flakes that would make it a better solution for pinning (in fact it’s a worse solution in at least one way) 
In fact, I’m very interested in using such tooling for individual package sources as well. Flakes definitely wouldn’t be a good fit there, because we don’t want a flake.nix file for every package (at least not in Nixpkgs) and it couldn’t support non-builtin fetchers.
Yes, the problem is that they are all third party tools.
I would really appreciate an official solution in the Nix CLI.
I think it’s not even that, it’s one standard method of composing Nix project that we really need; an interface between Nix projects. Flakes aim to be that standard.
Right, Flakes are also supposed to standardise the “entry point” of every Nix project.
As you are free to do, but but technological shorthand will not fix social problems. Social problems need social fixes, I know that is hard for the nix community to understand, even up to the board and the idea that you can “iterate on policy” (as if it were as easy as software iteration) – sure you can iterate but its quite difficult, as it is writing down a set of shared values for a world wide community. And that’s part of the reason why we are where we are.
I would support if it meant we could also move some projects/orgs & community identity could move off of Microsoft GitHub.
Surveying those flakes alternatives, they are all either locked to MS GitHub or locked to Git which is also concerning if Nix has fetchers for other VCSs like Bazaar, CVS, Darcs, Mercurial, Pijul, SVN.
Funny you should mention that. Pijul is probably the long-term best hope for decentralizing nixpkgs.
Whereas flakes try to make versioning more rigid by using lockfiles everywhere, Pijul goes in the opposite direction and makes versioning less rigid.
git merge and git rebase map to (literally) the same thing.pijul submodule because you can simply import another project’s patches into your repo and get the union of the two projects’ files.Adding pedantry, Darcs, still maintained, does the same patch-based thing & did it first providing the inspiration, not that it matters much.
Flakes doesn’t or other tooling doesn’t work well with either tool since you are expected to be about to point to a snapshot, but these are based on patches & necessary change order (patch operation is communicative)–even when the pristine doesn’t change. I have a feeling there would need to be some fundamental change to Nix to make it work ergonomically (see the comments in fetchdarcs & fetchpijul), but there’s an idea for your next OS & package management system 
Here are the first two sentences of the Pijul manual (emphasis added):
Pijul is the first distributed version control system to be based on a sound mathematical theory of changes. It is inspired by Darcs, but aims at solving the soundness and performance issues of Darcs.
I used Darcs for a long, long time. It was great, except that it was written by a physicist who did not spend enough time thinking about scaling issues.
I don’t think that is correct; there is no “change order”. A Pijul revision specifies an unordered set of (non-conflicting) patches. Using the unordered set of patches you can always reconstruct an exact snapshot of the pristine. Is there a more detailed example somewhere of this problem?
Regarding the comment in fetchpijul, we have the same problem with git: the contents of the .git directory after a git clone are not deterministic, because git doesn’t promise this. I don’t think pijul makes this promise for the database in .pijul/pristine/ either.
One of the things I didn’t like about Pijul when I tried it a year or two ago was that identity is tied to the host you’re using for your repositories. As far as I know, the only option currently is the Nest, and self-hosting Pijul repositories is not (yet?) supported.
While I don’t think splitting up nixpkgs is a good idea, I can agree with moving off GitHub. My contributing to nixpkgs is one of the only reasons I bother to keep a GitHub account instead of self-hosting my repos. Self-hosting a GitLab instance for nixpkgs might be one option, but I expect cost would be a significant factor.
This changed about a year ago (probably after you tried it), although the change had been in the works for years… and the new system is awesome. Your Pijul identity is now an ed25519 public key. This means that – unlike git – name changes are retroactive, so deadnames don’t appear in the version history. The mapping from public keys to usernames/firstlastnames is not (by default) part of the revision hash. Projects can choose to keep this mapping in-tree if they like.
Oh no that’s definitely not true; you’ve always been able to host a repository on any HTTP(S) server.
However :
Yes, that is currently the situation for forge software with a web browser GUI.
This is a concern that I share. It’s also bit of a touchy situation.
Pijul’s author has done an immense amount of awesome work, for which he has earned almost no money aside from NLNet grants. His current plan appears to be to run a “PijulHub” site (i.e. “the Nest”) as a business, sort of like github. I wish him the best and hope this works out. However it creates a slightly awkward situation where people feel guilty writing competing “Forge” software for Pijul and open sourcing it, since that would sort of sabotage the author’s plans. So, understandably, nobody does this.
I don’t really know what to do about this situation. I do acknowledge that it is a negative for Pijul.
That’s good to know. At the time, everything seemed tied to the Nest. I just wanted to self-host and sign my own commits There were other things I didn’t like about Pijul, but that was a big one for me.
Sorry, you’re right. I was thinking of forge software and not about plain repos (even though the latter is what I had wanted to self-host). I assume for nixpkgs that migrating to a repo without forge software would not be an option.
Perhaps this is getting too far into the weeds, but I’ve previously wondered how/whether pijul handles bisecting for a breaking change, which is (at least currently) something we need to be able to do.
A brief search again today suggests this still doesn’t exist–but it sounds like you have enough experience with it to have a sense of ground truth there?
Heh, thank you for putting that so gently. 
Yes, due to its sheer scale nixpkgs requires not just “a forge” but one that can deal with thousands of users hammering on it. And basically only github, gitlab, sourcehut and gitea/codeberg/forgejo are in that league today.
Let me be very clear: pijul is not going to solve any of nixpkgs’ problems tomorrow, this month, or realistically even this year. If github implodes tomorrow and we suddenly need a replacement, do not waste your time with pijul. But if we’re looking farther out – a year, two years from now – on that timescale and certainly beyond I think it is the most promising route.
An excellent question. Short answer: yes, you can, but it’s not automated yet.
Long answer: The state of a pijul repository (which is analogous to a git revision) is a set of patches. To use git bisect one of these revisions must be an ancestor of the other, so one of the corresponding pijul states would be a subset of the other. This means you can calculate the difference between the two sets, and do a bisection search on the patches in that difference: start by randomly cherry-picking half of them into the good/smaller/older state and test.
That’s the good news. The bad news is:
pijul log --state --output-format json, just like the early prototypes of git-bisect, but yeah this functionality definitely should be in the tool itself.I’m currently importing the nixpkgs history (all the way back to 2003) using the slow single-threaded pijul git importer. It’s up to mid-2018 at the moment. The import (single threaded!) will take at least a week to finish; I’ll post the result when it’s done, and hopefully an example of what a bisect would look like. It’s really interesting how some things (like adding commits) are a bit slower but other things are faster – for example, git blame pkgs/top-level/all-packages.nix takes 59 seconds, but pijul credit at the same point in history on the same hardware takes less than 2 seconds. Pijul’s internal representation is sort of like running git blame run on every file in every commit and then storing the output in a highly compressed format. So it takes more work to add new commits but you can query certain things much more efficiently.
Would you convert it? There isn’t any reason to keep the old history in Pijul.