Problem
Eighteen package repositories tell readers that the package "uses the
zsh-string-lib" to resolve its
manifest. None of them do. Zi reads package.json with .zi-parse-json in its
own lib/zsh/install.zsh, a vendored copy of @str-parse-json. Nothing in the
install path loads the library, and it is not a declared dependency anywhere.
The sentence is the same in each repository with the upstream project name
substituted, for example:
The [junegunn/fzf](https://github.com/junegunn/fzf) zsh package that uses the
[zsh-string-lib](https://github.com/z-shell/zsh-string-lib) to automatically:
It was copy-pasted at package creation; there is no template in this repository
that still generates it, so fixing a template will not fix the existing copies.
Affected repositories
- z-shell/any-gem
- z-shell/any-node
- z-shell/apr
- z-shell/asciidoctor
- z-shell/brew-completions
- z-shell/dircolors-material
- z-shell/doctoc
- z-shell/ecs-cli
- z-shell/firefox-dev
- z-shell/fzf
- z-shell/fzy
- z-shell/ls_colors
- z-shell/pyenv
- z-shell/remark
- z-shell/subversion
- z-shell/system-completions
- z-shell/zsh
- z-shell/zsh-bin
Why it matters
The claim is not merely stale, it misdirects. Someone debugging a manifest goes
and reads library source that is not the code being run, and the two copies have
already diverged: zi narrowed pair_map from ( "(" ")" "{" "}" "[" "]" ) to
( "{" "}" "[" "]" ), which is tighter for JSON. z-shell/zi#513 fixes two
further defects in the vendored copy that the library copy still has.
Change
Attribute the behavior to Zi's package support rather than to zsh-string-lib.
Where the historical relationship is worth keeping, state it as provenance, that
the parser originated in zsh-string-lib, not as a runtime dependency.
Acceptance
Context
Found while reviewing z-shell/zsh-string-lib and z-shell/zsh-util-lib for
possible adoption in Zi. z-shell/zsh#20 covers the z-shell/zsh copy and is
subsumed by this issue.
Problem
Eighteen package repositories tell readers that the package "uses the
zsh-string-lib" to resolve its
manifest. None of them do. Zi reads
package.jsonwith.zi-parse-jsonin itsown
lib/zsh/install.zsh, a vendored copy of@str-parse-json. Nothing in theinstall path loads the library, and it is not a declared dependency anywhere.
The sentence is the same in each repository with the upstream project name
substituted, for example:
It was copy-pasted at package creation; there is no template in this repository
that still generates it, so fixing a template will not fix the existing copies.
Affected repositories
Why it matters
The claim is not merely stale, it misdirects. Someone debugging a manifest goes
and reads library source that is not the code being run, and the two copies have
already diverged: zi narrowed
pair_mapfrom( "(" ")" "{" "}" "[" "]" )to( "{" "}" "[" "]" ), which is tighter for JSON. z-shell/zi#513 fixes twofurther defects in the vendored copy that the library copy still has.
Change
Attribute the behavior to Zi's package support rather than to
zsh-string-lib.Where the historical relationship is worth keeping, state it as provenance, that
the parser originated in
zsh-string-lib, not as a runtime dependency.Acceptance
zsh-string-libat installtime.
identified and corrected too, or its absence recorded.
Context
Found while reviewing
z-shell/zsh-string-libandz-shell/zsh-util-libforpossible adoption in Zi. z-shell/zsh#20 covers the
z-shell/zshcopy and issubsumed by this issue.