8000 fix(import): explicit src/url/dir overrides [1] shorthand, matching lazy.nvim by zuqini · Pull Request #36 · zuqini/zpack.nvim · GitHub
[go: up one dir, main page]

Skip to content

fix(import): explicit src/url/dir overrides [1] shorthand, matching lazy.nvim - #36

Merged
zuqini merged 5 commits into
mainfrom
fix/source-precedence
Aug 20, 2026
Merged

zuqini merged 5 commits into
mainfrom
fix/source-precedence

Conversation

@zuqini
@zuqini zuqini commented Aug 20, 2026
Copy link
Copy Markdown
Owner

[1] is now only a fallback for deriving the URL, so { 'user/repo', url = fork } installs the fork instead of silently ignoring the explicit source. New priority: dev > src > url > dir > [1].

zuqini added 5 commits August 19, 2026 18:48
…azy.nvim

[1] is now only a fallback for deriving the URL, so the fork-swap idiom
({ 'user/repo', url = fork }) installs the fork instead of silently
ignoring the explicit source. New priority: dev > src > url > dir > [1].
Two follow-ups to the src > url > dir > [1] precedence change so the
advertised fork idiom actually matches lazy.nvim:

- The plugin name now derives from [1] even when an explicit src/url/dir
  wins the source resolution, so { 'user/repo', url = fork } keeps the
  name "repo" regardless of the fork's basename (lazy.nvim derives the
  name from [1] first). Centralized in utils.resolve_plugin_name and
  used by merge, registration, and the public API.

- Spec fragments that share a [1] short name but normalize to different
  sources (base { 'user/repo' } plus override { 'user/repo', url = fork })
  now fold into one plugin at resolve time, mirroring lazy.nvim's
  name-keyed fragment merging. Without this, the precedence change made
  such configs abort setup() with vim.pack's conflicting-src error
  (previously the fork url was silently ignored). Dependency-graph edges
  built on the shorthand src are rekeyed onto the winning source.

Migration note: a spec mixing [1] with src/url/dir previously installed
from the [1]-derived GitHub URL; it now installs from the explicit
source under the [1]-derived name. The old install becomes an orphan
that :ZPack clean removes.

Also updates the stale dev.fallback chain order in doc/zpack.txt and the
src/name annotations in types.lua.
Two fragments sharing a [1] but carrying different explicit sources
(e.g. the same fork URL with and without .git across two spec files)
survived as separate registry entries deriving the same pack name, so
vim.pack.add aborted setup() with a conflicting-src error. Rework
coalesce_shorthand_overrides to group entries by the [1] shorthands
their specs carry and fold each group into one entry: dev-keyed entries
win outright (dev outranks the explicit chain), otherwise the latest
explicit fragment wins (lazy.nvim later-fragment-wins). Sweeps to a
fixpoint so folds that connect groups still converge deterministically.

Also document the reverse-graph no-empty-sets invariant guarding
rekey_graph_edges' asymmetric write, and fix the stale Spec.name doc
that still claimed the default name derives from the source URL.
The old merged_spec.name-or-plugin.spec.name chain yields nil while
entry.plugin is unpopulated, silently dropping a pin = true exclusion;
resolve_plugin_name never returns nil and agrees with the pack name by
construction.
- clear an emptied reverse-graph set when rekeying drops the old->new
  self-loop, preserving the no-empty-sets invariant
- re-sort the fold winner's specs in place so specs[1] stays the
  earliest-imported fragment (get_import_order reads it)
- pin 
8000
multi-sweep fold convergence with a chained-groups test
- lockstep comment tying fold_rank to normalize_source's precedence
@zuqini
zuqini merged commit 7b40442 into main Aug 20, 2026
4 checks passed
@zuqini
zuqini deleted the fix/source-precedence branch August 20, 2026 05:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

0