provide pre build binaries over CI or release

[Conni2461]

these should be downloadable with a script. So people without access to compiler and build systems can get an easier setup

[airtonix]

@Conni2461 I'd like to try tackle this.

Reading through #43 I am glad you went with cmake over what was initially proposed 👍🏻 .

As a part time windows user and full time linux user, I manually tried to provide myself some dlls. It wasn't trivial and I suspect most will give up.

So is good we are looking to automate this for users that want it.

From #43 it looks like you want this to be as simple and optional as possible for the end user:

1. user adds manifest line to their plugin manager
2. plugin manager installs telescope-fzf-native.nvim
3. a user specified post install step for the plugin downloads the binary as build/libfzf.so or build/libfzf.dll
4. user can now start using the plugin

Questions

1. your downloader

   • uses spawn and another external cli tool to download files from artifacts (instead of releases).
   • How tied to this implementation are you? (is there a reason why socket.http wouldn't work?)
   • Is a pure lua downloader acceptable ?

2. The release process

   • I suspect you used artifacts instead of releases because you wanted to avoid the step of tagging a commit as a release and all the ceremony regarding that?

     • From my experience doing CICD with github actions, releases provide a more stable platform to distributing artifacts than the artifacts system. This is because Github only intendeds for the artifact system to be a shortlived filestore between jobs and workflow runs. You can infer this from the maximum timeframe that Github allows you to retain logs and artifacts from workflow runs:
     • But it doesn't mean we have to start tagging things with semver if you want to have a "release on every commit to mainline branch" approach

   • Do you want :

     • a semver tag based release process where there are only releases when a commit on mainline is tagged? Release v1.2.3
     • or a release build for every commit on mainline branch? Release abcd1234
     • or a release build only when certain branch names are created release/.* 👉🏻 Release branch_name_here

3. What to build

   • Are we providing binaries for all platforms currently present in the ci.yml ?
   • I experienced another issue on windows with an unrelated plugin "treesitter" that wanted to compile things on the fly. I was able to get around it with relative ease by setting it to use clang instead of cc and then running scoop install llvm.
     • Is it possible to make a clang version of the Windows dll ? or is this fantasy?
   • Are we providing (And how do you want the filenames to look):
     • windows-x64-vc-libfzf.dll
     • darwin-x64-clang-libfzf.so
     • darwin-x64-gcc-libfzf.so
     • linux-x64-clang-libfzf.so
     • linux-x64-gcc-libfzf.so

[airtonix]

Ok first stage is done: automate the creation of a release with the various .so and .dll attached.

https://github.com/airtonix/telescope-fzf-native.nvim/releases

Next is the lua downloader that we can attach to some syntax like:

require('lazy').setup({
  {
    'nvim-telescope/telescope-fzf-native.nvim',
    build = function() require('telescope-fzf-native').download_library() end
  }
})

[airtonix]

Some more ideas here that might reduce management of releases:

• switch to using google-github-actions/release-please-action and a PR based release system
• add a PR title lint check to enforce PR titles follow conventional commit pattern (preferrably one that doesn't require config file by default, but allows one)
• configure repo to: only allow sqaush merge PRs, automatically use PR title as merge commit message, delete PR branches on merge
• configure branch protection for main: checks must pass, admins (you) can skip checks.
• modify workflow so that: push to main == dev release (@next) and merging a release PR == tagged versioned release.

This can be an optional follow up feature.

[airtonix]

Ok downloder works now with this syntax:

https://github.com/airtonix/dotfiles/commit/60466dff91b6470e63e6f16728ea24281e4309f0#diff-dff66fd5173223d1990816afcb91abfe64282dc87ee116052c4d91cfe2a9c4c9R6-R11

...
        { 'airtonix/telescope-fzf-native.nvim',
          branch = 'feature/69-prebuilt-release-binaries',
          build = function()
            require('telescope-fzf-native').download_library()
          end
        }
...

this is for lazy.nvim, I imagine it'll the same syntax for packer.

Last problem is this:

1. uninstall the plugin
2. load up nvim, causing lazy.nvim to install it
3. the postinstall step runs which downloads the dll and puts in the right place
4. the configure step runs, which fails because telescope doesn't thing the dll exists.
5. close nvim
6. launch nvim again, all is well.

I imagine what's going on is that something about the state of those files needs to be uncached?

• is this in telescope, lua or nvim?

[Conni2461]

You are amazing, implementing all this :heart:

your downloader

I didnt even remember writing one. ^^

I think i have a solution for the reloading issue, let me try to fix it.

There is a lot of stuff here, but lets move the conversation to the PR :)

[xchray]

what did I do wrong?

I am using LazyVim in corperate enviroment, so no authorization to install windows c++ build package. Thanks to prebuild, I am able to make it working. However, I have difficult to let LAZY to live with this. Below is my config.

however, the problem is, Lazy is always try to run CMAKE. After I copied dll to build, everything is working, but LAZY is not able to recognize it and always want to clean it.

what did I do wrong? Thanks so much.