Reposting previously private discussion to the bug thread. Hi Jonas,
I’m working on a hx-highlight-core package covering popular languages like Rust, Python, and Shell. To ensure compliance with Debian’s offline build requirements and Helix's specific version needs, I’m using the following two-phase approach: 1. Source Preparation: A script parses languages.toml for exact commit hashes, fetches the corresponding Tree-sitter sources, and aggregates them into a single, reproducible .orig.tar.xz tarball. 2. Build Phase: Using the debian/rules, the build compiles these local sources into .so files using a standard C compiler and installs them to a global directory, requiring no network access. This workflow maintains determinism while fulfilling the requirement for specific grammar snapshots. Does this approach align with your expectations and Debian packaging standards? Best regards, Junyong Liang On Tue, Apr 28, 2026 at 4:44 PM Smart SangGe <[email protected]> wrote: > Hi Jonas, > > I’m working on a hx-highlight-core package covering popular languages like > Rust, Python, and Shell. To ensure compliance with Debian’s offline build > requirements and Helix's specific version needs, I’m using the following > two-phase approach: > > 1. Source Preparation: A script parses languages.toml for exact commit > hashes, fetches the corresponding Tree-sitter sources, and aggregates them > into a single, reproducible .orig.tar.xz tarball. > 2. Build Phase: Using the debian/rules, the build compiles these local > sources into .so files using a standard C compiler and installs them to a > global directory, requiring no network access. > > This workflow maintains determinism while fulfilling the requirement for > specific grammar snapshots. Does this approach align with your expectations > and Debian packaging standards? > > Best regards, > Junyong Liang > > > On Sat, Apr 25, 2026 at 4:34 PM Jonas Smedegaard <[email protected]> wrote: > >> Quoting Smart SangGe (2026-04-25 08:24:34) >> > Hi Jonas, >> > >> > I’ve looked into the documentation and source code of both Helix and >> > Tree-sitter, and I must admit the situation is indeed challenging. >> > >> > One observation: the existing tree-sitter-*-src packages in stable >> appear >> > to be locked to specific version tags rather than individual commits. >> This >> > might cause some friction since Helix often tracks very specific (and >> > newer) snapshots of grammar repositories. >> > >> > I’m still interested in improving this. If you have a preferred >> > strategy—whether it’s grouping popular grammars into a single source >> > package or pushing for more individual grammar packages—please let me >> know. >> > I’d be happy to assist with the packaging work to help move this >> forward. >> >> Thanks for your interest in solving this, SangGe. You are very welcome >> to join me in the maintenance of helix. >> >> As I see it, there a several challenges here. I have tried to describe >> some of that already in earlier posts to this bugreport, so please read >> also earlier posts :-) >> >> I would prefer that helix plugins are packaged as separate source >> packages independently from helix itself. Reason for that is that I >> would prefer that the potential instability for supporting some fringe >> language would not affect the stability of helix itself or of support >> for other languages. That would probably require the src:hx package to >> provide a binary package hx-dev containing needed source files for such >> plugin source packages to build from. >> >> It makes sense to me to bundle plugins together. If possible to >> identify reasonably reliable, then I think the ideal would be to bundle >> source packages by stability and binary packages by runtime relations - >> e.g. having src:hx-plugins-core providing hx-plugins-shell (for bash >> and dotfiles and other common "core" formats) and hx-plugins-python >> (for python3 and python-related formats) and hx-plugins-c (for C and >> cpp related classic formats) etc., and src:hx-plugins-extra providing >> various sets of less common format plugins. >> >> I don't mind bundling Rust crates - please see the source code for how >> I already do that for tree-house. And please do ask, if you cannot >> understand how that embedding is established using git-buildpackage and >> watch file and copyright file. >> >> Kind regards, >> >> - Jonas >> >> -- >> * Jonas Smedegaard - idealist & Internet-arkitekt >> * Tlf.: +45 40843136 Website: http://dr.jones.dk/ >> * Sponsorship: https://ko-fi.com/drjones >> >> [x] quote me freely [ ] ask before reusing [ ] keep private >> >
