Fetch GitHub SPDX license metadata during plugin updates and emit meta.license for generated vim plugin derivations.
Fall back to lib.licenses.unfree when no SPDX license is detected, and round-trip existing license metadata through get-plugins.nix so partial updates do not drop it.
Previously it evaluated `nvim-treesitter-legacy` derivation, which now
results in a warning. Checking for pname shouldn't raise this warning,
since now only plugins that are installed get evaluated.
Compare the current source ref using src.tag when present and fall back to
src.rev otherwise.
nvim-treesitter can now be represented by either a tag or a commit depending on
how the updater selected its target. Comparing only rev makes the special-case
skip logic treat equivalent tagged sources as mismatches.
Keep fetcher tag metadata when reading current plugin state from Nix.
The updater needs to know whether a plugin was fetched by tag or by commit.
Without carrying src.tag through, tagged sources are read back as if rev were
always the canonical source identifier, which breaks tag-aware comparisons and
cache behavior later in the update flow.
buildNeovimPlugin removed in previous update, but get-plugins is trying
to call package with removed argument.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
We have machinery for Python packaging, so let’s make use of
it. This also helps unblock moving `by-name` overrides out of
`all-packages.nix`, as it was previously being used to work around
`nixpkgs-vet` forbidding the direct reference to the path.
What if some grammar fails to update? Well, it gets removed from the
generated file. How would we know that the grammar failed? By reading
logs. Who reads logs if the command didn't crash? Right, nobody. Or even
if someone examines the logs, it is too easy to overlook the failure
(are you sure you read every single line of code? It is not even colored)
They are useful only in two cases:
- During debugging, this happens rarely
- Let's print something to keep the user informed that we are doing
something
It should not to be a mistake to overlook one line from the logs,
because when you run the same script hundreds of times (we do updates
weekly), you barely look at logs; you scan them, at most.
By treating logs this way, we can inform ourselves about possible
breakages before it gets even reviewed by another person, not by a user
opening a bug report months later.
Upstream no longer updating the sources in the lockfile.json, but they
still update in their main branch's parsers.lua. We don't need to parse
that file since nurr is already doing that for us. We can just grab
latest parser info from their json.
