all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Roel Janssen <roel@gnu.org>
Cc: Guix-devel <guix-devel@gnu.org>
Subject: Re: [PATCH] gnu: graphviz: Enable Guile library.
Date: Thu, 19 May 2016 14:08:06 +0200	[thread overview]
Message-ID: <87oa82w8rd.fsf@gnu.org> (raw)
In-Reply-To: <87a8joxtgd.fsf@gnu.org> (Roel Janssen's message of "Tue, 17 May 2016 23:31:14 +0200")

Roel Janssen <roel@gnu.org> skribis:

> Ludovic Courtès writes:
>
>> Roel Janssen <roel@gnu.org> 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	other threads:[~2016-05-19 12:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-09 10:17 [PATCH] gnu: graphviz: Enable Guile library Roel Janssen
2016-05-09 20:37 ` Ludovic Courtès
2016-05-09 20:54   ` Roel Janssen
2016-05-10  5:53     ` Danny Milosavljevic
2016-05-10  9:15       ` Roel Janssen
2016-05-10 13:08         ` Roel Janssen
2016-05-10 13:31         ` Ludovic Courtès
2016-05-10 14:07           ` Roel Janssen
2016-05-11 14:04             ` Ludovic Courtès
2016-05-11 14:48               ` Roel Janssen
2016-05-11 16:22                 ` Ludovic Courtès
2016-05-11 21:55                   ` Roel Janssen
2016-05-17 20:48                     ` Ludovic Courtès
2016-05-17 21:31                       ` Roel Janssen
2016-05-19 12:08                         ` Ludovic Courtès [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87oa82w8rd.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=roel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.