Automatically download fzf binary if not found

[junegunn]

Have you considered making fzf-lua download a proper fzf binary from GitHub if it's not on $PATH or the version requirement is not met? It will make it easier for a new user to get started and to have a better experience. Just my two cents.

That's what fzf/fzf.vim currently does. There is a function called fzf#exec([min_version]) for plugin developers that returns the path of an fzf binary that can be used;

• If fzf is not found on $PATH, it downloads the latest version from GitHub using the install script, puts it under bin directory, and returns the path
• If fzf is found on $PATH, but it's older thanmin_version, it does the same

:echo fzf#exec('1.2.3')

You need fzf 1.2.3 or above. Found: 0.57.0. Download binary? (y/n)

So a plugin developer can call that function to ensure that the version requirement is met.

• https://github.com/junegunn/fzf.vim/blob/556f45e79ae5e3970054fee4c4373472604a1b4e/autoload/fzf/vim.vim#L110-L122

You can make fzf-lua work with older versions of fzf as in ee7d3ad. But then the users will miss out on improvements and bug fixes in the later versions of fzf. For example, they won't benefit from the performance optimizations in 0.50.0 and 0.49.0 and will have a suboptimal experience.

[ibhagwan]

Hi @junegunn, ty for sharing your thoughts on the subject.

Have you considered making fzf-lua download a proper fzf binary from GitHub if it's not on $PATH or the version requirement is not met? It will make it easier for a new user to get started and to have a better experience. Just my two cents.

I have thought about it but I have a slight aversion to having the plugin make internet connections and download something, feels to me like a breach of user privacy and it also includes a significant risk should the users’ environment be compromised, man in the middle attack, ssl proxy etc, that means I’d have to also implement SHA-256/512 verification (or better yet GPG?) but obviously that significantly increases the complexity of the task.

And that’s without even mentioning the issues and troubleshooting I’d have to do for various networking issues of users, for example a corporate user sitting behind a firewall which replaces the SSL cert and trying to curl…

This, to me, sounds like a bit of over complication for a task I believe should be under the responsibility of the user, not very hard to accomplish and also empowers that user to understand what they have installed rather than having 2 copies of fzf (one in /bin and another in a local bin).

But then the users will miss out on improvements and bug fixes in the later versions of fzf. For example, they won't benefit from the performance optimizations in 0.50.0 and 0.49.0 and will have a suboptimal experience.

Absolutely correct, it’s much more than that too, if using a version newer than 0.36 fzf-lua utilizes a different way (using reload/load/bind/unbind events) to not terminate the fzf process for “reload” actions resulting in a much better UX, for example, staging in git_status without the UI flashing or the cursor moving.

Aside from the above and as “general policy” in fzf-lua (and perhaps a bit different than neovim rapid development plugins), I try to never break anything or force the user to change anything, hell fzf-lua still works with fzf 0.25 and neovim 0.5 (I actually test this regularly, lol), at worst I’ll provide a warning message with renamed option descriptions, there’s nothing more annoying than updating your plugin at the wrong time and now trying to figure out what went wrong, the upgrades and config updates should happen when the users’ are in the right mood for it.

Anyways, these are my 2 cents and I lean towards a “no” for auto-download but obviously open for discussion.

[junegunn]

I understand your point.

fzf is a hard dependency of your project, thus I don't think making it easier to get it with user confirmation is not any form of breach of privacy. Any non-trivial modern software project has some dependencies, and users expect the build scripts to automatically resolve them, not to tell them to manually download and inspect them one by one. However good your intentions are, they will not appreciate when they are told to do so. You just need to be transparent about what you're doing under the hood.

As for the compromised systems, I would say that's thinking too much. We are required to place trust in several entities when we use an open source project. No one thoroughly reads the source code before using an open-source plugin. Also, if the system is compromised, we wouldn't know if the source code downloaded from GitHub is intact; it may have been mutated to bypass all the meticulous security measures. Even if the user manually installs fzf, but the system is compromised, the end result will be the same anyway (the only difference is that we can say that it's their fault). So, again, I think it's enough to be transparent (i.e. Can I curl https://something to your plugin directory? (y/n) Doesn't work? Sorry to hear that, try it yourself and investigate.)

I'm not trying to argue with your points, I think they are truly valid concerns. I just wanted to share a different perspective.

hell fzf-lua still works with fzf 0.25 and neovim 0.5 (I actually test this regularly, lol)

That's actually one of the reasons I posted this. You can save a lot of effort and focus on improving things just by making sure that a certain version of fzf is available.

Anyway, this is not at all an urgent issue. Happy new year!