On Tue, Nov 5, 2024 at 2:29 PM Peter Oliver via packaging <packaging@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > I have a couple of questions regarding packaging Tree-sitter parsers for Fedora. Hi, Thank you for starting this discussion! > Some background. 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. > > Official bindings are available for using the parsers from a number of languages (https://tree-sitter.github.io/tree-sitter/#language-bindings). 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, pypi.org for Python, etc.). > > First question. Should we be building all bindings we care about for a parser from a single SRPM (using the upstream source code), rather than making a bunch of duplicate SRPMs (one for each language, from the language-specific releases)? I think a single SRPM per parser makes more sense, but it does have the drawback of making the .spec files more complicated, and prevents us from generating them with, say, rust2rpm. This is kind of against the spirit (or the rules) for packaging projects that are available on PyPI and on crates.io. For Rust crates, we even have a MUST NOT rule for building rust-*-devel packages from non-crates.io sources. There is one exception for Rust crates - when they're part of a larger project and not feasible to be packaged separately. But that is obviously not the case here - we already have tree-sitter crates from crates.io packaged in a compliant way. So in this case the "convenient" solution of building all the bindings from the upstream project is not compliant with the packaging guidelines for Rust crates (even a MUST NOT rule violated right now). *If* it is guaranteed that the code published on crates.io is the same as the one in tagged upstream releases, then I think we *could* make an exception here. However, even then, the packages would need to be compliant with the Rust packaging guidelines. I don't think this is easy to do in the current form. For example, the spec file in the "rust" branch here: https://src.fedoraproject.org/rpms/tree-sitter-java/blob/rust/f/tree-sitter-java.spec has problems - it can't be generated by rust2rpm, and it's currently *only* correct because the project has no feature flags other than "default". > This brings me to my second question. Spec files for different Tree-sitter parsers are pretty-much identical to each other, so should we generate them using macros? This sounds like it would be a good idea, especially if all the packages would be essentially identical other than having a different "tree-sitter-$lang" name and source repo. If we end up making this an acceptable way to build the Rust bindings, macros to build and generate the "rust-*-devel" subpackages correctly would definitely help too. Fabio -- _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
