On Wed, 6 Nov 2024, Fabio Valentini via packaging wrote:
we already have tree-sitter
crates from crates.io packaged in a compliant way.
Not that it really changes the argument, but I don’t think we have any for Tree-sitter parsers, yet, which are what we’re discussing here.
*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.
Guarantee is a strong word, but if there are differences, then I think we can consider that a bug. Official Tree-sitter parsers have automation to build the various release artefacts from a git tag (e.g., https://github.com/tree-sitter/tree-sitter-java/blob/master/.github/workflows/publish.yml).
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".
I’m tempted to say that we could cross this bridge when we come to it (if ever). Given that the Rust code and Cargo configuration is copied from a template when the parser developer runs the `tree-sitter generate` command, I think variation from parser to parser will be rare, and hence we can make a one-size-fits-all .spec in a simple-minded way.
I accept, though, that it would not be ideal to have Rust packaging assumptions hard-coded into something that isn’t part of the Rust packaging tooling.
There’s a trade-off here between consistent Rust packaging, versus getting Rust subpackages “for free” when Tree-sitter parsers are packaged for other languages (and vice versa). I think that’s something for people with more Rust packaging experience than me to weigh up.
--
Peter Oliver
--
_______________________________________________
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
