--- Begin Message ---
|
Subject: |
[PATCH 0/3] Add generic JSON importer |
|
Date: |
Sun, 27 Aug 2017 17:58:20 +0200 |
Hi Guix,
this patch set adds a somewhat unusual importer. Assume we have a file
"package.json" with the following contents:
--8<---------------cut here---------------start------------->8---
{
"name": "hello",
"version": "2.10",
"source": {
"method": "url-fetch",
"uri": "mirror://gnu/hello/hello-2.10.tar.gz",
"sha256": {
"base32": "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"
}
}
"build-system": "gnu",
"home-page": "https://www.gnu.org/software/hello/";,
"synopsis": "Hello, GNU world: An example GNU package",
"description": "It really works.",
"license": "GPL-3.0+",
"inputs": ["address@hidden", "ghc-pandoc", "address@hidden"]
}
--8<---------------cut here---------------end--------------->8---
Let’s run the new “json” importer on this file:
--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix import json package.json
(package
(name "hello")
(version "2.10")
(source
(origin
(uri (string-append
"mirror://gnu/hello/hello-2.10.tar.gz"))
(method url-fetch)
(sha256
(base32
"0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
(build-system r-build-system)
(inputs
`(("r-minimal"
,(@ (gnu packages statistics) r-minimal))
("ghc-pandoc"
,(@ (gnu packages haskell) ghc-pandoc))
("samtools"
,(@ (gnu packages bioinformatics) samtools-0.1))))
(home-page "https://www.gnu.org/software/hello/";)
(synopsis
"Hello, GNU world: An example GNU package")
(description "It really works.")
(license gpl3+))
--8<---------------cut here---------------end--------------->8---
What you don’t see here is that the JSON importer internally creates a
package object, which could already be built (e.g. from within the REPL)
— without having to write it to a file first and setting
GUIX_PACKAGE_PATH.
What is this good for? Users could create simple Guix packages for
their own immature projects using a syntax that they may be more
familiar with and generate a proper Scheme package definition from it to
allow other people to install it. For more complicated packages they
would, of course, be better served by using the usual Scheme syntax for
package definitions.
To make the importer behave like all other importers, we use the new
“package->code” procedure, which takes a package and generates the code,
which would create an equivalent package object when evaluated.
There are some minor problems with “package->code”, which are marked
with FIXME comments. We probably shouldn’t print out “(@ (gnu packages
statistics) r-minimal)” and instead let “package->code” return two
values: the package code and a list of modules needed to evaluate it.
What do you think? Terrible? Exciting? Both? *raises hand*
Documentation of this importer is missing because I’m not sure if this
is the best way of doing this. Let’s discuss!
~~ Ricardo
Ricardo Wurmus (3):
packages: Add package->code.
import: Add generic data to package converter.
import: Add JSON importer.
guix/import/utils.scm | 77 ++++++++++++++++++++++++-
guix/packages.scm | 131 +++++++++++++++++++++++++++++++++++++++++++
guix/scripts/import.scm | 2 +-
guix/scripts/import/json.scm | 101 +++++++++++++++++++++++++++++++++
4 files changed, 309 insertions(+), 2 deletions(-)
create mode 100644 guix/scripts/import/json.scm
--
2.14.1
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: [bug#28251] [PATCH 1/3] packages: Add package->code. |
|
Date: |
Thu, 28 Sep 2017 13:19:21 +0200 |
|
User-agent: |
mu4e 0.9.18; emacs 25.3.1 |
Ludovic Courtès <address@hidden> writes:
> Ricardo Wurmus <address@hidden> skribis:
>
>> * guix/packages.scm (package->code): New procedure.
>
> We’ll need tests for this. :-)
I’ve added some simple tests to tests/print.scm and import-utils.scm.
> I would move it to (guix import utils) or a new (guix import print)
> module or similar (which will also allow us to use ‘factorize-uri’). In
> my mind, eventually all importers will produce a <package> object
> directly, and so this will be a core part of the import machinery.
> Since it’s not a crucial component, I would prefer to have it out of
> (guix packages) though.
Okay, done.
>> +;; FIXME: the quasiquoted arguments field may contain embedded package
>> +;; objects, e.g. in #:disallowed-references; they will just be printed with
>> +;; their usual #<package ...> representation, not as variable names.
>
> Not sure how to solve that; maybe we can ignore for now.
That’s why I originally experimented with overriding the printer. For
the purposes of a JSON importer, however, this really isn’t important.
>> +(define (package->code package)
>> + "Return an S-expression representing the source code that produces PACKAGE
>> +when evaluated."
>
> Like you wrote, it would be nice to also return a spec of modules in
> scope, like:
>
> ((gnu packages r)
> ((guix licenses) #:prefix license:))
>
> WDYT?
I’ll leave this as a later improvement, but yes: I’ll add this at some
point.
> I think we should compare values with ‘eq?’ (usually we’re concerned
> with pointer identity of records), and also use ‘module-for-each’ +
> ‘let/ec’ to avoid building a list for nothing
That’s good!
> Nitpick: I’d rename all the ‘print-*’ procedures to ‘*->code’.
Done.
I’ve implemented the other suggested changes and added some
documentation. I’ll push it to master in a few minutes.
Thanks for the comments!
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
--- End Message ---