guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] gnu: graphviz: Enable Guile library.


From: Ludovic Courtès
Subject: Re: [PATCH] gnu: graphviz: Enable Guile library.
Date: Thu, 19 May 2016 14:08:06 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Roel Janssen <address@hidden> skribis:

> Ludovic Courtès writes:
>
>> Roel Janssen <address@hidden> skribis:

[...]

>>> I am definitely interested in adding an option to directly output an
>>> SVG in the graph subcommand, for which graphviz-guile is a
>>> prerequisite.
>>
>> It’s definitely tempting, but on the downside, note that we’d have to
>> support the case where the Graphviz Guile bindings are missing, provide
>> additional command-line options to tweak the output, etc. when in fact,
>> the only visible benefit would be that one can type:
>>
>>   guix graph --format=pdf foo > foo.pdf
>>
>> instead of:
>>
>>   guix graph foo | dot -Tpdf > foo.pdf
>>
>> (The latter is one character shorter, even!  ;-))
>
> Well, we could go for:
>
>   guix graph foo --file=foo.pdf
>
> Even shorter! ;-)  The default can stay the same, so one can still tweak
> using the dot program.
>
> More importantly, by using the graphviz library we don't need the user
> to install dot to convert it to a graphics format.

Currently Graphviz is a “soft dependency” of Guix: the ‘guix graph’
command is always built and installed, and it’s up to the user to
install Graphviz if they want to pipe things through ‘dot’.

If we use-modules (graphviz), then we’ll have to write a bunch of code
that still allows ‘guix graph’ to build and run even when the (graphviz)
module is missing, etc.  That’s always kind of boring and occasionally
fragile.

In both cases, the user needs to install Graphviz to get PDFs and such.
However, this is more work for us if we add an optional dependency on
the (graphviz) module, and not much better from the user’s viewpoint.

> However, at that
> point the graphviz library becomes a dependency of Guix.  Making it a
> dependency of Guix opens the possibility of moving the Guile module file
> into guix/graphviz.scm and make it part of Guix.

I think we should refrain from adding such a module in Guix; it should
be part of Graphviz itself.

>> So, thinking more about it, I think that in the case of ‘guix graph’,
>> it’s a bit of trouble for little in return.
>>
>> WDYT?  :-)
>>
>> Ludo’.
>
> I think it depends on whether it would be a problem to add the graphviz
> library as a dependency to Guix.

It would be a problem to depend on a (graphviz) module that is in fact
no distributed as part of Graphviz.

> The return is not so much the shorter (or longer ;-)) command, but
> more the completeness of Guix to produce a graphical output rather
> than a text file that can be used by another program to generate
> graphical output.
>
> If you think I should put my energy elsewhere on the project, I can and
> will respect that ;-).

Maybe it’s a good idea indeed, but I’ll let you judge that.  :-)

Thanks,
Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]