Hi,

Andrew Tropin <andrew@trop.in> writes:

> [[PGP Signed Part:Undecided]]
> On 2023-02-10 15:48, Pierre Langlois wrote:
>
>> Hi Andrew, thanks for pushing this along! It's great to see things
>> getting merged.
>>
>> Andrew Tropin <andrew@trop.in> writes:
>>
>>> [[PGP Signed Part:Undecided]]
>>> On 2023-02-09 18:04, Andrew Tropin wrote:
>>>
>>>> On 2023-02-09 13:39, zimoun wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Thu, 09 Feb 2023 at 14:11, Andrew Tropin <andrew@trop.in> wrote:
>>>>>
>>>>>> I applied tree-sitter and tree-sitter-cli patches,
>>>>>
>>>>> Just to be sure to understand, you have only applied 02/32 and 05/32,
>>>>> right?
>>>>>
>>>>>
>>>>> [bug#49946] [PATCH v7 02/32] gnu: tree-sitter: Update to 0.20.7.
>>>>> id:20221125012142.22579-3-pierre.langlois@gmx.com
>>>>> http://issues.guix.gnu.org/msgid/20221125012142.22579-3-pierre.langlois@gmx.com
>>>>>
>>>>> [bug#49946] [PATCH v7 05/32] gnu: Add tree-sitter-cli.
>>>>> id:20221125012142.22579-6-pierre.langlois@gmx.com
>>>>> http://issues.guix.gnu.org/msgid/20221125012142.22579-6-pierre.langlois@gmx.com
>>>>>
>>>>> Leaving out all the others, right?
>>>>
>>>> Merged first 5 patches from 01 to 05, also added one more commit, which
>>>> addresses some things from reviews and one commit, which adds html
>>>> grammar.
>>>>
>>>> The html grammar is added for the testing purposes.  It relies on
>>>> generated parser.c and scanner.c and we will need to repackage it using
>>>> grammar.js instead.  I'm not sure if a separate build system is needed
>>>> for this, I guess we can just rewrite tree-sitter-grammar function,
>>>> which generates packages as in example with tree-sitter-grammar-html:
>>>> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/tree-sitter.scm?h=53b00b91b73bd60412d5bd057e22e6d63194a7f7#n158
>>>>
>>>> Anyway, I only skimmed tree-sitter-build-system source code, and plan to
>>>> read it carefully, evaluate and either introduce new build system or
>>>> just move all needed parts to tree-sitter-grammar function.  WDYT?
>>>> After we done with it we can package all other grammars.
>>>
>>> Ok, I realized that the proper build process for tree-sitter grammars is
>>> a little harder than I expected, tree-sitter-build system make sense.  I
>>> reviewed it, made a small change:
>>
>> Ah great, I was going to comment to try and push for us to keep the
>> build system. I originally went with a template package and inheritance,
>> but Maxime suggested moving to a build-system which ended up making the
>> package definitions a *lot* nicer IMO (see previous discussion here
>> https://issues.guix.gnu.org/49946#144). It also allows us to deal with
>> grammars that depend on each other more nicely I think.
>>
>>>
>>> @@ -29,7 +29,7 @@ (define-module (guix build tree-sitter-build-system)
>>>  ;; Commentary:
>>>  ;;
>>>  ;; Build procedures for tree-sitter grammar packages.  This is the
>>> -;; builder-side code, which builds on top fo the node build-system.
>>> +;; builder-side code, which builds on top of the node build-system.
>>>  ;;
>>>  ;; Tree-sitter grammars are written in JavaScript and compiled to a native
>>>  ;; shared object.  The `tree-sitter generate' command invokes `node' in order
>>> @@ -114,7 +114,7 @@ (define (compile-language dir)
>>>                     "-fno-exceptions"
>>>                     "-O2"
>>>                     "-g"
>>> -                   "-o" ,(string-append lib "/" lang ".so")
>>> +                   "-o" ,(string-append lib "/libtree-sitter-" lang ".so")
>>>                     ;; An additional `scanner.{c,cc}' file is sometimes
>>>                     ;; provided.
>>>                     ,@(cond
>>>
>>>
>>> rewrote html grammar to use this build system and made it work with
>>> built-in treesit package.  Also, tried examples of c and cpp grammars
>>> from patches in this thread.
>>>
>>> If you ok with it, I'll push the build system to master and update the
>>> html grammar accordingly.
>>>
>>> The final result will look like this:
>>>
>>> (define tree-sitter-delete-generated-files
>>>   #~(begin
>>>       (delete-file "binding.gyp")
>>>       (delete-file-recursively "bindings")
>>>       (delete-file "src/grammar.json")
>>>       (delete-file "src/node-types.json")
>>>       (delete-file "src/parser.c")
>>>       (delete-file-recursively "src/tree_sitter")))
>>>
>>> (define* (tree-sitter-grammar
>>>           language language-for-synopsis version commit hash
>>>           #:key
>>>           (repository-url
>>>            (format #f "https://github.com/tree-sitter/tree-sitter-~a" language))
>>>           (inputs '()))
>>>   (let ((synopsis (string-append language-for-synopsis
>>>                                  " grammar for tree-sitter"))
>>>         (name (string-append "tree-sitter-grammar-" language)))
>>>     (package
>>>       (name name)
>>>       (version version)
>>>       (home-page repository-url)
>>>       (source (origin
>>>                 (method git-fetch)
>>>                 (uri (git-reference
>>>                       (url repository-url)
>>>                       (commit commit)))
>>>                 (file-name (git-file-name name version))
>>>                 (sha256 (base32 hash))
>>>                 (modules '((guix build utils)))
>>>                 (snippet tree-sitter-delete-generated-files)))
>>>       (build-system tree-sitter-build-system)
>>>       (inputs inputs)
>>>       (synopsis synopsis)
>>>       (description (string-append synopsis "."))
>>>       (license license:expat))))
>>>
>>> (define-public tree-sitter-grammar-html
>>>   (tree-sitter-grammar
>>>    "html" "HTML"
>>>    "0.19.0" "v0.19.0"
>>>    "1hg7vbcy7bir6b8x11v0a4x0glvqnsqc3i2ixiarbxmycbgl3axy"))
>>>
>>> After that we can bring the rest of the grammars.
>>
>> I would suggest to rmeove the `tree-sitter-grammar' function, and keep
>> grammars as "regular" package records, even though it's a little bit
>> more verbose:
>>
>> --8<---------------cut here---------------start------------->8---
>> (define-public tree-sitter-html
>>   (package
>>     (name "tree-sitter-html")
>
> It seems tree-sitter-html mimics upstream package name and probably make
> more sense than tree-sitter-grammar-html used by me.

Yeah, at some point I think I had named the packages with "grammar" as
well, but thought it was a bit of a mouthful.  I'm also thinking one day
we may build language bindings as part of the build system (Rust and
NodeJS I think ATM), so those packages could do more than ship the
grammar in the future (although we don't know if we'll ever really need
that).

>
>>     (version "0.19.0")
>>     (source (origin
>>               (method git-fetch)
>>               (uri (git-reference
>>                     (url "https://github.com/tree-sitter/tree-sitter-html")
>>                     (commit (string-append "v" version))))
>>               (file-name (git-file-name name version))
>>               (sha256
>>                (base32
>>                 "1hg7vbcy7bir6b8x11v0a4x0glvqnsqc3i2ixiarbxmycbgl3axy"))
>>               (modules '((guix build utils)))
>>               (snippet tree-sitter-delete-generated-files)))
>>     (build-system tree-sitter-build-system)
>>     (home-page "https://github.com/tree-sitter/tree-sitter-html")
>>     (synopsis "Tree-sitter HTML grammar")
>>     (description
>>      "This package provides a HTML grammar for the Tree-sitter library.")
>>     (license license:expat)))
>> --8<---------------cut here---------------end--------------->8---
>>
>> This way, they look like any other package in Guix, which makes it
>> easier for us to apply automatic changes in the future if needed (for
>> example like how the input format could be automically updated for all
>> "simple" package definitions, but had to be manual whenever custom code
>> refactoring was done). Does this make sense?
>
> Make sense, but on the other hand we already have hunspell, aspell
> dictionaries and probably a few more others, which are very similiar in
> spirit and we already have to keep in mind their existence on such
> automatic code updates.
>
> It looks that the packages differ only in url for the source code, lang
> name and sometimes in inputs.  Having template package function can make
> management of shared parts more centralized, reduce possibility of
> copy-paste mistakes, when the description wasn't updated and so on and
> can reduce the amount of the code overall (which also reduces the change
> of introducing an error).
>
> I don't have a strong opinion on this topic, but leaning towards the
> template function slightly more, however I'm completely ok with the
> standalone package definitions as well.  WDYT?

I can think of both cost/benefits to the template so I don't have a
strong opinion either :-).

I do like the template to make sure people don't forget to delete
generated files, that's quite important as it seems upstream packages
often check-in the generated C code.  Although, we could probably assert
that with in the build-system phase?  I'll think about that.

On the other hand, I wonder how the template works for packages that
provide multiple grammars (see ocaml and typescript for example).  I
guess we could use the template for trivial packages, and standalone
definitions for more complex ones?  In general, if we keep the template
interface really simple, then I'm happy with it.

Thanks,
Pierre