compe-tabnine icon indicating copy to clipboard operation
compe-tabnine copied to clipboard

[Bug] TabNine keep downloading itself making it unusable with compe-tabnine Neovim plugin

Open pidgeon777 opened this issue 4 years ago • 7 comments

General Informations:

  • OS version: Windows 10 x64 Pro build 1809
  • Editor: Neovim + compe-tabnine
  • Editor version: NVIM v0.6.0-dev+14-gdf33f30e8
  • Programming language: all
  • TabNine extension version: TabNine
  • 3.4.29 (x86_64-pc-windows-gnu)
  • Engine version (could be located within Tabnine Hub): N/A

Issue Details:

My compe-tabnine plugin folder is structured as follows:

C:\Users\MyUsername\AppData\Local\nvim-data\site\pack\packer\start\compe-tabnine\binaries

Inside of the binaries folder, the following executables are placed:

  • TabNine_Windows.exe
  • TabNine-deep-cloud.exe
  • TabNine-deep-local.exe
  • WD-TabNine.exe

The fact is that often, new files are created by TabNine when it updates itself, for example in this folder:

  • C:\Users\MyUsername\AppData\Local\nvim-data\site\pack\packer\start\3.5.31\binaries

After the automatic update process, the newly created folder will contain:

  • TabNine.exe
  • TabNine-deep-cloud.exe
  • TabNine-deep-local.exe
  • WD-TabNine.exe

As a result, the originally started process TabNine_Windows.exe will keep crashing because of the newly released TabNine update, which should be run instead. compe-tabnine plugin will detect TabNine_Windows.exe crash and it will try to start it again, in an endless loop. In the end, this makes Neovim unusable.

I only see three solutions for this annoying behaviour:

  • Disable TabNine automatic update with a command-line flag: in no way TabNine should crash itself when a new edition is released unless instructed to do so.
  • Instruct the compe-tabnine plugin to always point at the new TabNine.exe downloaded executable, and run that instead, unless a new version is released, and if so point again at the new executable location.
  • Allow a way to update TabNine by letting it stop its execution, deleting itself and downloading the new executable at the same path as the original one, possibly maintaining the same filename too.

I would like to hear your opinion about this, and how could this be fixed. Until that, TabNine is not usable in Windows with the Neovim client.

pidgeon777 avatar Jul 24 '21 14:07 pidgeon777

https://github.com/codota/TabNine/issues/425

pidgeon777 avatar Jul 24 '21 14:07 pidgeon777

If you look at the install script, Windows is not currently supported. Any patches fixing the issue are welcome; please make sure to handle all the different ways neovim can be installed in Windows.

tzachar avatar Jul 25 '21 04:07 tzachar

I don't know if I have the necessary knowledge to do that.

Anyway, I would like to start from what seems to be the major issue: when running TabNine.exe, the process check if a new version exists. If yes, it downloads it to a different location, as shown above, and it terminate itself.

Is this behaviour caused by compe-tabnine, or it is related to TabNine itself?

pidgeon777 avatar Jul 25 '21 11:07 pidgeon777

If you look at the install script, and check the binaries directory, you can see that we link to the last TabNine binary which was downloaded by compe-tabnine. The way TabNine works is that once it downloads a newer version of itself, it will usually exec the latest version available. TabNine will also look for the latest version installed once invoked and will start it. This all works on linux and mac, I realy don't know why it goes into an infinite loop on windows.

tzachar avatar Jul 25 '21 16:07 tzachar

Is this still an issue?

tzachar avatar Aug 09 '21 08:08 tzachar

Yes. I'm trying to find a way to solve this issue in Windows 10.

Maybe making use of symbolic/hard links, as in Unix OS, could help?

We could link the current TabNine_Windows.exe executable to the newly downloaded executable, instead.

Some code in the LUA script which could check for patterns of the newly downloaded file path, and link TabNine_Windows.exe to that new executable, instead.

And do this everytime a new binary is downloaded (scan the base path looking for the newly downloaded binary).

The format of the newly downloaded binary is the one I described in my previous messages.

pidgeon777 avatar Aug 10 '21 15:08 pidgeon777

Please try using #33 We dispense with the links there.

tzachar avatar Aug 11 '21 07:08 tzachar