Why does this repo use just? What does it do better than nix run?

[hab25]

No description provided.

[akirak]

@hab25 Did you have a look at the content of justfile? It basically runs a bunch of nix commands with varying options. It would be possible to wrap them in several apps/packages in the flake, but that would require more boilerplate code. I use just simply because I thought that would make the configuration more concise. Actually, those tasks were initially in the GitHub workflow, but I moved them to justfile to make the test suite portable. just is only used for testing, so it does not add a runtime dependency for users.

[hab25]

@akirak thank you, at this point you have answered everything I really wanted to know (i.e., whether there was something special about just I wasn't aware of); so I'm just replying to your points in case you are interested in discussing.

Did you have a look at the content of justfile?

Yes.

but that would require more boilerplate code. I use just simply because I thought that would make the configuration more concise.

My opinion is that implementing the functionality of just that this project uses in nix is so trivial and requires so little code (i.e., probably just a few let-binds to share common commands) that it is not worth the additional dependency.

just is only used for testing, so it does not add a runtime dependency for users.

That is good, but for contributors (and/or the CI environment), it introduces the typical downsides of adding another dependency as it increases:

• the learning floor when contributing to those tests
• the potential for malware
• the potential sources of bugs
• disk space

[akirak]

the learning floor when contributing to those tests

If someone finds the justfile in this repository too difficult to understand, I don't think he/she can contribute to the Nix code of this project. I learned the syntax in three minutes or so, faster than composing this message to you. The problem would be documentation though, I'll need to write a contribution guide, if I want contributions.

the potential for malware

If just is installed from nixpkgs, it is reviewed by a package maintainer on every package upgrade, rather than blindly fetching the latest revision from Git. You can't use NixOS without basically trusting this process. This project assumes GNU Emacs and most packages (that are manually reviewed) from nixpkgs are safe.

It's also run on CI, so the user doesn't necessarily have to run it locally.

the potential sources of bugs

Nix isn't bug-free, either. casey/just has 196 open issues now, while nixos/nix has 2.6k. They can't be directly compared for many reasons, but Nix itself is quite a potential source of bugs! I use Nix not because it doesn't have a bug, but because there are benefits of using it even if it has some bugs. You could have bugs even by writing a trivial shell script. I use just for developer experience, to resolve bugs in this project efficiently.

disk space

just is very small in instalation size. On the other hand, building a Nix derivation consumes storage space every time any of its inputs changes. The storage cost used by just is negligible here.

My opinion is that implementing the functionality of just that this project uses in nix is so trivial and requires so little code (i.e., probably just a few let-binds to share common commands) that it is not worth the additional dependency.

I don't want to further complicate flake.nix in test directory, so it's meaningful to keep them separate. Putting them in flake.nix also brings a risk of accidentally running the test suite from outside of the project tree.

[hab25]

These are reasonable opinions.

Putting them in flake.nix also brings a risk of accidentally running the test suite from outside of the project tree.

This risk can be eliminated by making a file in the project tree named with a newly generated UUID (e.g., from uuidgen) and checking for its existence as the first step of any command.

However, with the above solution, one couldn't run the test suite from outside the project tree and with the current directory appropriately set, as just allows. Hence, this is an ergonomic convenience that just has over (pure) Nix.

In fact, looks like a fair number of people want this and there's a related open issue NixOS/nix#8034.

[akirak]

a fair number of people want this and there's a related open issue NixOS/nix#8034.

Thank you for the pointer. I don't always stay up-to-date with the current status of Nix and its ecosystem.