TL;DR: Should Rust bindings for Tree-sitter parsers be packaged independently (using the usual Rust packaging process), or should they be a subpackage of the main Tree-sitter parser package (effectively giving us Rust bindings for free, but not using rust2rpm, etc.)?
Here’s the long version. Tree-sitter is a library for writing parsers for source code, for use in, for example, syntax highlighters and text editors. Nearly 500 different parsers are available separately (https://github.com/tree-sitter/tree-sitter/wiki/List-of-parsers). However, we only have one of them packaged for Fedora so far, with Rust bindings proposed for one more (https://bugzilla.redhat.com/show_bug.cgi?id=2318053).
Spec files for Tree-sitter parsers will all be very similar to each other, and could probably be generated by simple-minded RPM macros (a draft of which are at https://src.fedoraproject.org/rpms/tree-sitter/pull-request/1#request_diff).
Official bindings are available for using the parsers from a number of languages, including Rust. The Tree-sitter project has tooling to automatically generate these bindings, which are committed to the Git repository of each parser. On release, the bindings are uploaded to the native repository for each language (i.e., crates.io for Rust).
This gives us a choice:
- We could treat Rust bindings for Tree-sitter as any other crate, with the souce fetched from crates.io. If someone wanted them, they would need to package them in the usual Rust way.
- We could package Rust bindings for Tree-sitter as a subpackage of the package that builds the parser as a C library, with the source fetched from github.com. We would have Rust bindings for every Tree-sitter parser packaged for Fedora. The Tree-sitter-specific RPM macros used in these packages may need tweaking in future to keep up with any changes to the Rust packaging guidelines.
Which sounds preferable?
By the way, I have asked this question on the packaging list (https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject....), but it didn’t generate much discussion. I will also ask the equivalent question on the Python list.
On Tue, Nov 26, 2024 at 2:52 PM Peter Oliver via Rust rust@lists.fedoraproject.org wrote:
TL;DR: Should Rust bindings for Tree-sitter parsers be packaged independently (using the usual Rust packaging process), or should they be a subpackage of the main Tree-sitter parser package (effectively giving us Rust bindings for free, but not using rust2rpm, etc.)?
Well, you'll get the same response from me here as on the "packaging" list ...
In theory, both approaches (1. building from published Rust crate, vs. 2. building the Rust crate from the GitHub release) *should* work, though I have doubts about how reliable option 1 would be.
However, without additional work and changes to our current guidelines for Rust crates, option 2. won't work and won't be allowed.
Fabio
On Sun, Dec 1, 2024 at 7:11 PM Fabio Valentini decathorpe@gmail.com wrote:
On Tue, Nov 26, 2024 at 2:52 PM Peter Oliver via Rust rust@lists.fedoraproject.org wrote:
TL;DR: Should Rust bindings for Tree-sitter parsers be packaged independently (using the usual Rust packaging process), or should they be a subpackage of the main Tree-sitter parser package (effectively giving us Rust bindings for free, but not using rust2rpm, etc.)?
Well, you'll get the same response from me here as on the "packaging" list ...
In theory, both approaches (1. building from published Rust crate, vs. 2. building the Rust crate from the GitHub release) *should* work, though I have doubts about how reliable option 1 would be.
This should obviously have been "how reliable option 2 would be" - sorry about that.
However, without additional work and changes to our current guidelines for Rust crates, option 2. won't work and won't be allowed.
Fabio
-
Fabio Valentini -
Peter Oliver