Concerns about autodownloading z.sh
z0rc opened this issue · 6 comments
f7de596 introduced automatic download of z.sh, which I hardly find acceptable, for multiple reasons.
- It isn't documented anywhere.
- If you really want to have this plugin to autoinstall
z, you can bundle it as git submodule instead of downloading it, because this way you can actually update it after initial installation. - Most important in my case, I already have
zinstalled, but it's pure zsh implementation zsh-z, and I would like to continue using it because it's more performant due to less forking.
Okay, that being said, here is my proposal. Ideally I recommend to check whether z is available and ask user to install it, if it isn't present. The nature of this project clearly indicates, that it depends on having z installed and available. If z isn't available, ask user to install it first. The way fzf-z downloads and uses z isn't actually working as expected, because sourcing z has effect only in zlist.sh shell (btw, why it uses bash?) and user's shell still won't be using z hooks.
Overall the current approach has its flaws and it isn't clear what problems it solves.
Hi, thanks for your comments.
Totally agree this could/should be documented better - so apologies if I caused confusion there. I'll fix that once we come to a conclusion here, including producing a message/asking permission when/whilst z.sh is lazy-downloaded.
The reason for needing an additional copy of z.sh is simple - that commit factored out fzf-z functionality into a standalone command, and in particular for z -l (which lists the frecency directories), it cannot call the z command typically provided by the user's plugin manager as that's not available in non-interactive shell scripts. fzf-z still needs the user to install z anyway in addition for the precmd/postcmd (and the two should be compatible). If there's a solution to that I've missed, great - but unfortunately at the moment z is not packaged as a standalone command.
A submodule would be an option, and I'll take a look at that, although that may make this plugin more fiddly to install for many zsh plugin managers.
Interim improvements to warnings/docs in this commit: 21b2cab.
Well, at this case I won't be using this plugin anymore. Benefits of having fzfz shell script are minuscule to me comparing to expressed concerns and downloading anything without user's consent is a red flag to me.
OK, I'm sorry to hear that. One potential option which I will consider is to reimplement the logic for z -l (which is presumably fairly simple) in fzf-z - if that's something you'd be interested in helping with, let me know. I've added some warnings in the interim.
Honestly, I'm not sure I'm interested in this. As I was using this plugin only in interactive mode and will probably hack something together to match personal preferences.
Since I don't know of any easy way to fix this for using fzfz as a command, and I think that's valuable extra flexibility, I'm going to close this. Note that fzf-z now supports using fasd instead of z (which is superior anyway, it appears), and which doesn't require this "dynamic download" behaviour.