I was considering using pijul to manage my nix flakes, but since nix flakes seem heavily tied to git and hg, I’m not sure how to do this. On the Flakes - NixOS Wiki this is written after all: “Warning: flake makes a strong assumption that the folder is a git or mercurial repository. It doesn’t work outside of them.”
1 Like
I don’t know, I’m not super familiar with flakes, because I couldn’t get them to work for everything I wanted (like deploying nest.pijul.com). The NixOS maintainers are aware of the existence of Pijul, I believe the main missing thing to have a proper fetchPijul in nixpkgs would be the tag command, which at the moment depends on the new backend (the new Sanakirja). So, there’s nothing much I can do at the moment, except finish that (very long and tedious) integration job.
1 Like
Huh, thanks!
金, 2月 19, 2021 at 11:39, Pierre-Étienne Meunier via Pijul <pijul@discoursemail.com> が送信：
Aren’t states and channels enough? Or if not, what are states then/where are they explained?
That’s a bit too strong a statement, I think: There are path and tarball fetchers, so flakes needn’t be VCS repos at all. Certainly it helps with reproducability if you have an archive of uniquely identified versions.
Has there been any movement in this topic recently?
I’ll hazard a guess that Pijul has all the features that Nix expects a VCS to have. Now it’s up to the Nix program to integrate Pijul the way it does Git and Hg. Not only does there need to be a fetchPijul function for flake inputs, but for the flake itself it needs to be able to detect that the folder is controlled by Pijul, checkout the flake into the Nix store using the version checked out locally and…oh that might be all. I didn’t realize before today that flakes supported Mercurial, so it probably isn’t that hard to add a third integration.
One thing that is hard is that tags aren’t fully implemented in Pijul. The current version has tags, they work as expected but aren’t as fast and small as they could be, by orders of magnitude.
nix is functional, right? The OS is rebuilt each time with patches, that’s their selling point if I’m not wrong, so you’d think it’d be right up their street.
Basically, Pijul is to Git what nixos is to containers/ostree, more or less replacing trees with a composable DAG. There’s a lot of overlap between their philosophies.
So as mentioned above, the only thing it needs is bit-for-bit reproducibility that can be checked with cryptographic hashing, checking out from a remote repository based on a hash, and solid tagging. And then just doing these things fast enough to not be a bottleneck and being mature/stable enough that you can continue to rely on the hashes even after future updates.
1 Like
I made a plugin to add Pijul support to Nix flakes, see the readme: dblsaiko/nix-plugin-pijul
However, it can’t automatically detect that the current directory is a Pijul repo, since that seems to be hardcoded in Nix to only detect Git repos. (However I do have a patch to Nix for that)
5 Likes