Andy Wingo <wi...@igalia.com> skribis:
> Concretly I would propose something like this in a package.scm in the
> git repo:
>
> (use-modules (guildhall)) ; or whatever we call it
> (import-guix-packages ((a "a")
> (b "b@5.2")))
>
> (define foo
> (guildhall-package
> (name "foo")
> (inputs
> `(("a" ,a)
> ("b" ,b)))
> (git-url "https://github.com/foo/foo";)
> (home-page "https://github.com/foo/foo";)
> (synopsis "Foo is a thing")
> (build-system simple-guile-build-system)
> (description
> "It's a thing")
> (license license:expat)))
>
> I guess you would not want to load this file from the web service as it
> has arbitrary Scheme code inside it. I could see solutions where only
> the end-user tool loads this file and exports data to the server, and
> the server creates an appropriate "normal" package definition using just
> the Guix API. It can write those definitions out to disk. It would
> export a progressing git repository of Guix package definitions. As
> Guix API changes, that server could re-render those package
> descriptions. Of course that only works in some limited cases.
> Otherwise you as a user could do this rendering process for packages you
> are developing. Maybe it is a good thing to encourage nontrivial
> packages to go upstream to Guix.
Sounds like a reasonable approach.
BTW, there’s a simple actionable item here, which is to write that
‘guile-build-system’ in Guix. Currently, for Scheme-only packages, we
often more or less copy/pasted stuff like this:
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile.scm#n733
If this were packaged in a ‘guile-build-system’¹, the barrier to
submitting Guile packages would already be lower.
Ludo’.
¹ See <https://gnu.org/software/guix/manual/html_node/Build-Systems.html>.
