The wrapper referenced no jre at all: propagatedBuildInputs put one in the
closure but on nobody PATH, so the client found a java only if the user
happened to have one, and overriding jre changed nothing at run time.
Now that the wrapper carries it, the propagation is redundant and was
pushing the jre into the build environment of every dependent. Dropping
it does mean bloop no longer puts a java on the PATH of anything that
takes it as an input, `nix-shell -p bloop` included; add a jre alongside
it if you relied on that.
Assisted-by: Claude Code (Claude Opus 5)
Asks GitHub for the latest release, prefetches every asset sources.json
lists and rewrites the file, so that r-ryantm can bump this package the
way it already bumps scala-cli.
The script takes no arguments and knows nothing about bloop: the
repository, the current version and even which sections of assets exist
are read out of sources.json, which is found through meta.position of
$UPDATE_NIX_ATTR_PATH. writeShellApplication runs shellcheck over it at
build time.
It supports the `commit` updateScript feature:
nix-shell maintainers/scripts/update.nix --argstr package bloop --arg commit true
Assisted-by: Claude Code (Claude Opus 5)
Checks the wrapper and the autopatchelfed binary answer --help, which is
the only thing that works without network access: everything that reaches
the build server downloads it from Maven Central first.
Assisted-by: Claude Code (Claude Opus 5)
The version and the per-platform asset names and hashes become data,
replacing the two if/else chains that selected them. A following commit
adds an update script, which can then rewrite JSON instead of Nix.
meta.platforms is derived from the asset list, so the two cannot drift,
and meta.changelog can be built from the same data.
The fetchurl calls move from derivation attributes into let bindings; they
were only ever used through string interpolation in installPhase, so being
attributes just put their store paths in the build environment.
Assisted-by: Claude Code (Claude Opus 5)
meta.platforms has never listed x86_64-darwin, so the branch selecting
this asset was unreachable and its hash was never checked against
anything.
Assisted-by: Claude Code (Claude Opus 5)
Upstream replaced the fish-completions asset of every release at some
point, but the hash here has not changed since 1.5.11. A fetchurl whose
hash still matches resolves out of the binary cache no matter what the URL
now serves, so nothing ever failed and users kept getting the 2023
completions.
Assisted-by: Claude Code (Claude Opus 5)
Also migrates away from them with these commands, using ast-grep 0.43.0
with these commands in bash (assisted by ChatGPT):
```bash
for old in extractType1 extractType2; do
ast-grep \
--lang nix \
--pattern "\$TOOLS.$old" \
--rewrite '$TOOLS.extract' \
--update-all \
pkgs
done
ast-grep \
--lang nix \
--pattern '$TOOLS.wrapType1' \
--rewrite '$TOOLS.wrapType2' \
--update-all \
pkgs
```
Assisted-by: GPT-5.6-Sol Medium via ChatGPT
