This hook should make people think before committing domain names
like "radicle.xyz" and "radicle.zulipchat.com" to our Rust code.
Note that these checks can be easily skipped as follows:
SKIP=grep-radicle.xyz,grep-radicle.zulipchat.com git commit …
See also <https://pre-commit.com/#temporarily-disabling-hooks>
1. Introduce a new hook to run `cargo doc` in the "pre-commit"
phase. We have to resort to wrapping the command in a shell
script, since we cannot configure environment variables via
`.pre-commit.yaml` but need `RUSTDOCFLAGS` so that `cargo doc`
actually exists non-zero when there are warnings.
2. Move `cargo check` from the "pre-push" to the "pre-commit"
phase, as it is relatively quick, and redundant to run before
`clippy`.
3. Let `cargo check` and `cargo doc` run after `rustfmt`.
4. Let a failure of `rustfmt` fail the whole check.
5. Wire through `packageOverrides` to `rustfmt` so we use the
same toolchain as the other tools.
6. Additionally enable `cargo clippy` to consider all features.
This prepares the crate versions for a new release. The version bumps were
determined by the `cargo-semver-checks` tool.
However, there were some issues with the `radicle-fetch` crate – where when
attempting to check it, it was unable to compile due to the previous version
expecting the kind of `Doc` with a generic parameter. I believe this is due to
the version for `radicle` being specified as simply `0`. This prompted changing
the version specifications to use `major.minor` for all the internal crates.
This, for example, would mean that `radicle-fetch` that relies on `0.15` can use
`>=0.15.0,<0.16.0` – allowing any patch versions but must require a minor
version bump.
These hook take relatively long on my machine, and my impatience has
lead to me doing `git commit --no-verify`, which defeats the purpose of
having these hooks.
Note that others (like `alejandra`, `cargo fmt` and `shellcheck`) are
reasonably fast and will keep doing good.
The nix flake's checks were failing for various reasons. The following fixes are
applied to get it up to date again.
- Update to release-24.11, since `crane` requires it – also to keep up-to-date
- Add `.json` to the source filters to allow for testing patch migration
- Ensure that the `rad` and `git-remote-rad` binaries are built for the nextest
check. N.b. the binaries need to be in the target dir of `radicle-cli` since
that is where the nextest check runs from.
- Add `cargo-audit` and `cargo-deny`, to the devShell, to allow for running those
tools locally
- Bump `gix-path` to 0.10.11 to avoid a vulnerability[^0]
[^0]: https://rustsec.org/advisories/RUSTSEC-2024-0371
* Remove empty `inherit`s
These were not doing anything.
{ inherit (f) x; }
is equivalent to
{ x = f.x; }
but
{ inherit (f); }
is equivalent to
{}
since there is no attribute name given.
* Refactor `srcFilters` to use `any`
That's more lighweight and easier to extend.
* Use `installShellFiles` for `buildManPages`
* Produce a more stable version
* Move package `radicle` next to the others
It's nothing special!
* Refactor Flake
More code reuse, and a little more direct, basically.
* Set environment variable on derivation
* Compress even more by removing special crate
* Use `with pkgs` before lists of packages
* Use system-independent `lib`
* Clean up
* Update `flake.lock`
* Enable checks `audit`, `deny`
To ensure the Nix derivations are using the correct toolchain, defined
in the `rust-toolchain` file, use the `rust-overlay` library.
Also remove the `fenix` input, since this was actually never used and
was an artefact of some copy-paste shenanigans.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Since sqlite is used for the databases, including the sqlite3 binary
in the devShell is useful for debugging purposes.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
There is no need for the ';' in the `.envrc` file.
Do not run checks in devShell so that it's possible to enter the shell
while code is being edited and is not compiling. Also include
`cargo-nextest` so that one can test in the shell.
Signed-off-by: Fintan Halpenny <Fintan Halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
Nix Flakes[[0]] are a more modular way of expressing nix derivations.
The `flake.nix` file describes:
- How to build the project, or components of a projet, via `nix build`
- What "checks" can run for a project, which can be executed via
`nix flake check`
- What binaries can be run, e.g. `nix run .#rad` to execute the CLI
This approach is preferable since a lot of the Nix ecosystem is using
Flakes -- despite it still being marked as experimental.
One interesting benefit, that needs confirming, is that a check can be
run from a remote Git source. So if someone creates a patch on
Radicle, someone else with the `nix` binary can execute:
nix flake check git+https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5?refs=patches/<patch id>
This means that anyone with `nix` can check patches without having to
fetch the patch itself.
Another obvious benefit will be that it allows the Radicle binaries to
enter the Nix ecosystem.
The big caveat to both of the above is that, currently, the tests are
failing while running `nix flake check`. They are currently disabled
with `doCheck = false`. They are potentially failing due to some
strange sandboxing issues which are being looked into.
[0]: https://nixos.wiki/wiki/Flakes
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett