Rust December 2024

rust@lists.fedoraproject.org

3 participants
3 discussions

Orphaning some CLI tools (written in Rust)
by Fabio Valentini 02 Jan '25

02 Jan '25

Hi all, Doing some end-of-year "does this still spark joy?" type of chores, I decided to orphan a few packages for command-line tools (written in Rust) that I picked up at some point but which I myself don't use: - rust-git-delta - rust-gitui + rust-asyncgit - rust-sd - rust-silver Some notes for potential maintainers: Some of these don't see regular updates - sd and silver are years old at this point. rust-git-delta, rust-gitui, and rust-silver all depend on the Rust bindings for libgit2. This is a constant pain point, because they need to be patched for new libgit2 bindings versions to address security issues in the bundled libgit2. (Yes, *not* using the bundled libgit2 was considered, and was considered *worse*. The Rust bindings only ever support *one* specific minor version of libgit2, and silently / subtly break with other versions due to ABI incompatibilities.) A number of similar packages I don't use were already redistributed internally in the Rust SIG: - rust-bat - rust-fd-find - rust-lsd - rust-tokei Three of these (bat, lsd, tokei) *also* depend on the libgit2 Rust bindings, and share the maintenance annoyances of the other packages. :) Happy Holidays. Fabio

3 4

Advise on packaging a Rust app
by Antoine Tenart 20 Dec '24

20 Dec '24

Hello, [Resending as first email was rejected; wasn't a member of the list] We'd like to package a Rust application for Fedora, Retis[1]. We currently distribute it in COPR[2] because we can't easily follow the Fedora Rust packing rules at the moment but that is far from being perfect (on all levels). Don't get me wrong, I think the packaging rules make sense; but those are a high entry barrier for projects with multiple unpackaged complex dependencies (recursively). We wrote a plan with detailed steps to get there, https://github.com/retis-org/retis/milestone/13. It's basically divided into the following directions: - Take over / upgrade some outdated dependencies. - Package the missing dependencies in Fedora. Some are easier than others to package / maintain. - Remove the use of other dependencies. There are a few issues to overcome (packaging complex dependencies takes time, I think we have a dep of a dep w/o a license, etc) but most importantly I think the concern is with maintenance; especially when it's not trivial. All that of course will be quite an effort so we thought we should ask for your input and advises on if this is the right direction or if you have some comments? Also we're wondering if there's anything that could ease the process or make the delay shorter (eg. vendoring *some* deps temporarily)? The above also raises an additional question: any additional dependency added upstream, if not already packaged and non trivial, could gate upcoming releases from being packaged. Gating upstream development on downstream packaging doesn't look right and I guess those kind of issues are just expected (we already have one coming); but wanted to ask just in case :) Thanks! Antoine [1] https://retis.readthedocs.io/en/stable/ [2] https://copr.fedorainfracloud.org/coprs/g/retis/retis/

2 8

How to package Rust bindings for Tree-sitter parsers?
by Peter Oliver 01 Dec '24

01 Dec '24

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. -- Peter Oliver

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

Rust December 2024