[Top][All Lists]

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

Re: Data dirs and shepherd services

From: Ricardo Wurmus
Subject: Re: Data dirs and shepherd services
Date: Mon, 12 Nov 2018 12:40:58 +0100
User-agent: mu4e 1.0; emacs 26.1

Hi Edouard,

> - My software needs to serve a bunch of static files. Those belong to a
> package that is 'propagated-input' installed with the big metapackage of
> the whole software.
> By using
> $guix package list-installed
> I can see the store directory of the metapackage, but the propagated-inputs
> packages are not listed, and I don't know how to find their store
> directories. The question here is multifold:
> - Those static files are linked in .guix-profile: is referring to those
> links the correct way of referring to them ? Because I need to serve them
> via a webserver and I don't want to serve my whole .guix-profile dir, it
> may prove cumbersome.

The way I would do this is to add a build phase that creates a link to
the the directory of the other package that should be served.  Then you
only need to serve the target package’s “share/<name>/public” (or
similar) directory.

> - Is there a way of knowing the store dir of an arbitrary package ? Would
> this be the correct way of referring to those static files ?

Yes.  When you do this in a build phase all you need to do is refer to
the other package via “(assoc-ref inputs "label")”, where “inputs” is
bound to the list of all package inputs and “label” is the string label
that identifies the input you are interested in.

On the command line you can get the store path to any package by using
“guix build the-package”.  The result is the store path.

> - Can I specify an out-of-store static dir (such as e.g. /opt/var/www)
> where to copy or link the files when installing the package ? Ideally I'd
> like to do that in the package description, but a command line switch would
> be OK as well.

No, you can’t do that as part of the package build.  Packages can only
write to their very own build output directory (or “directories” when
using more than one output); they are all under /gnu/store.

You can, however, specify a Guix system service, which *can* access
otehr locations when started.  That’s also how we would accomplish the
“temp zone” (see below).

> Next, my software needs a temp zone where to store user files (those can be
> destroyed across reboots). This zone should be organized with multiple
> dirs, some static files, etc. I assume the store dir of the package is not
> the correct place to put these dirs

That’s correct.

> - Is it OK to use the store dir as a user-provided data storage place ? I
> assume not.

It is not okay.  The store is read-only.

> - How can I specify an out-of-store storage place (e.g.
> /opt/share/my_software)  in the package description ?

You can do this with system services only.  We have a bunch of services
that set up /var/cache or /run/foo and then run the executable provided
by a package with a generated configuration file referencing these

> Finally, I hope to use GNU shepherd to start my software, but the
> documentation on how to write a service is not there yet:
> Do you know of any examples I could draw inspiration from ?

This depends on what kind of setup is required for your service.  A
system service may include a shepherd service, but it can do more than
that.  You could, for example, look at the service for Cuirass (the CI
system we use for Guix), which is a web server with a database; the
system service sets up the directories and includes a shepherd service
that starts the web server.

Hope that helps!


reply via email to

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