GNU bug report logs -
#28251
[PATCH 0/3] Add generic JSON importer
Previous Next
Reported by: Ricardo Wurmus <rekado <at> elephly.net>
Date: Sun, 27 Aug 2017 15:59:01 UTC
Severity: normal
Tags: patch
Done: Ricardo Wurmus <rekado <at> elephly.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#28251: [PATCH 0/3] Add generic JSON importer
which was filed against the guix-patches package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 28251 <at> debbugs.gnu.org.
--
28251: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=28251
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Ludovic Courtès <ludo <at> gnu.org> writes:
> Ricardo Wurmus <rekado <at> elephly.net> 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
[Message part 3 (message/rfc822, inline)]
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": ["r-minimal <at> 3", "ghc-pandoc", "samtools <at> 0"]
}
--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
This bug report was last modified 7 years and 298 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.