Plugin manager v2

[foxfriends]

Plugin manager v2

[adamdicarlo0]

Hi! Trying out syncat for the first time, and getting it to build and run on nix / NixOS. (That was actually quite easy!) I've only used it a little so far but it seems awesome!

More suggestions for the package management:

For Nix users

Allow using a build-time env var to dictate where tree-sitter parsers should be loaded from, so Nix users can install the treesitter parsers with Nix. The Nix module/flake for syncat could build a default set of parsers, and let you override the list by passing in the parsers' nix packages. 🤔

⚠️ I'm not certain a build-time env var is the best approach; I'm not a Nix expert and haven't written any Rust.

For non-Nix users

• Change the default path for tree-sitter parser installs to $XDG_STATE_HOME/syncat (see XDG_STATE_HOME) - $XDG_CONFIG_HOME isn't the best place for installing compiled binaries
• Use git clone --depth 1 to avoid gigabytes of git history from the various parsers' repositories (tree-sitter-ocaml's .git folder is 2.6G)
• Don't clone tree-sitter-ocaml recursively, if possible--it has 19 submodules, and they all get cloned into examples/ so (I presume) they aren't required

Thanks for making this project!

[foxfriends]

Allow using a build-time env var to dictate where tree-sitter parsers should be loaded from

This sounds like a great idea, unrelated to Nix at all. Even a runtime env var would likely work just fine? As the parsers are dynamically linked/loaded anyway, they can be located at runtime from anywhere. Though I know nothing about how Nix works, maybe that's not going to work for you guys, you'd have to tell me on that one!

Considering some possible approaches:

• Env var to specify the folder in which to find languages
• Env var specifying an override for the languages.toml config file, which can then point to parser folders directly (by absolute or relative path)
• Allow specifying override env variables/command line flags to override any setting of a languages.toml entry on the fly (e.g. for one off/testing a parser use cases)

Thanks for the suggestions :)

[foxfriends]

Have implemented some of your suggestions in 3.7.0:

• There is a new command line argument -c/--config which allows specifying the directory in which to find configuration files. Would be possible to make this into an environment variable later on, but that can wait, since this behaviour is easily adaptable using aliases or something yourself
• I removed --recursive from the default clone args, and now clone_args and pull_args are options that can be specified in the languages.toml file. I tried to see if --depth 1 would work for the default, but it seems when you shallow clone a repository, then pulling becomes hard/impossible in the naive case, so I could not make this the default... you're welcome to specify clone_args = ["--depth", "1"] on ocaml yourself in the config now though, but it'll then be up to you to manually update the repository (or just syncat remove ocaml; syncat install ocaml) to update it, since the pull command won't work.
• (Admittedly didn't really test this part but) in theory should be possible to set the library field of the language in languages.toml to an absolute path, if you prefer your languages installed into XDG_STATE_HOME instead of XDG_CONFIG_HOME. A bit manual of a task now, to change that for your own config file, but I may change the default for this in future (I'll check up on that link you linked!)

[adamdicarlo0]

Oh, that's awesome, thank you!! 🚀 I wasn't considering the update (git pull) case for the packages, so a full clone does make sense. For Nix use, Nix would manage installing (and thus "upgrading") the tree-sitter parsers. It looks like Syncat's install command builds an object file in each parser directory (for interop with Syncat, I presume), so that will need to be part of the Nix build. I think I'll be able to build a decent Nix flake for Syncat... 🤔

[foxfriends]

Yes I think if the tree sitter binaries are compiled the way syncat needs them, it will work... if nix is already generating that file (just with a different name/location) it does seem reasonable to allow overriding the name of the file in the languages.toml file as well so that it can be located from anywhere, if that helps at all.