RFC: writable private scratch XDG_CACHE_HOME in build enviroment?

RFC: writable private scratch XDG_CACHE_HOME in build enviroment?

[Andy Wingo]

Hi,

Guile will try to automatically compile .scm files and cache them in
XDG_CACHE_HOME.  When building Guile itself, Guile sets XDG_CACHE_HOME
to ${top_builddir}/cache.  What if we would set this ourselves for all
packages?  That way all packages could benefit from a scratch location
when building that wouldn't propagate to the outputs.

In Fibers I have some tests that I assume get compiled.  If they're not
compiled, they go quite slow (260s vs 5s).  Alternately I could add a
XDG_CACHE_HOME setting in Fibers.  Which should we do?

Regards,

Andy

Re: RFC: writable private scratch XDG_CACHE_HOME in build enviroment?

[Mathieu Lirzin]

Hello Andy,

Andy Wingo <wingo@igalia.com> writes:

> Guile will try to automatically compile .scm files and cache them in
> XDG_CACHE_HOME.  When building Guile itself, Guile sets XDG_CACHE_HOME
> to ${top_builddir}/cache.  What if we would set this ourselves for all
> packages?  That way all packages could benefit from a scratch location
> when building that wouldn't propagate to the outputs.
>
> In Fibers I have some tests that I assume get compiled.  If they're not
> compiled, they go quite slow (260s vs 5s).  Alternately I could add a
> XDG_CACHE_HOME setting in Fibers.  Which should we do?

IIUC the problem you have is that in a Guix build environmnent, Guile
tries but *fails* to autocompile ".scm" files because it doesn't find
any directory that it can write on?

Even if I would not recommend relying on autocompilation in a build
process (or anywhere else) I agree that it would be reasonable to have a
way to autocompile ".scm" files in a Guix build environment.

Since /tmp is writeable in a Guix build environment and in most POSIX
systems (I guess), Would it make sense for Guile itself to fallback to
/tmp for its compilation cache?

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: RFC: writable private scratch XDG_CACHE_HOME in build enviroment?

[Andy Wingo]

Hi :)

On Tue 21 Feb 2017 13:13, Mathieu Lirzin <mthl@gnu.org> writes:

> IIUC the problem you have is that in a Guix build environmnent, Guile
> tries but *fails* to autocompile ".scm" files because it doesn't find
> any directory that it can write on?

Correct.

> Since /tmp is writeable in a Guix build environment and in most POSIX
> systems (I guess), Would it make sense for Guile itself to fallback to
> /tmp for its compilation cache?

It's possible.  It's a bit gnarly though:

  * you get the usual race conditions between users and /tmp that you
    have to mitigate

  * you have to be more careful about permissions (it could be that the
    .go embeds something secret)
    - each user would have to have their own path here

  * guile would have to look in /tmp in addition to XDG_CACHE_HOME when
    looking for autocompiled files

  * what if the one in /tmp is fresh but the one in XDG_CACHE_HOME is
    not, or vice versa?

I'd rather use XDG_CACHE_HOME for this as it's already well specified
and actually not Guile-specific
(https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html).

Andy

Re: RFC: writable private scratch XDG_CACHE_HOME in build enviroment?

[Mathieu Lirzin]

Andy Wingo <wingo@igalia.com> writes:

> On Tue 21 Feb 2017 13:13, Mathieu Lirzin <mthl@gnu.org> writes:
>
>> IIUC the problem you have is that in a Guix build environmnent, Guile
>> tries but *fails* to autocompile ".scm" files because it doesn't find
>> any directory that it can write on?
>
> Correct.
>
>> Since /tmp is writeable in a Guix build environment and in most POSIX
>> systems (I guess), Would it make sense for Guile itself to fallback to
>> /tmp for its compilation cache?
>
> It's possible.  It's a bit gnarly though:
>
>   * you get the usual race conditions between users and /tmp that you
>     have to mitigate

Nothing different from the race conditions for a single user using
XDG_CACHE_HOME when compilation is done by multiple threads?

>   * you have to be more careful about permissions (it could be that the
>     .go embeds something secret)
>     - each user would have to have their own path here

Indeed.

>   * guile would have to look in /tmp in addition to XDG_CACHE_HOME when
>     looking for autocompiled files
>
>   * what if the one in /tmp is fresh but the one in XDG_CACHE_HOME is
>     not, or vice versa?

This two last points makes me think of a the general issue with caching.
Maybe we could apply the the sane principles of memoization by computing
the "value" of a file (by hashing it?) and search it in the different
".go" stores (GUILE_LOAD_COMPILED_PATH, XDG_CACHE_HOME, site-ccache,
...)?

I don't know if the idea is stupid or not, maybe I miss an obvious
point.  Anyway this doesn't fit the purpose of fixing your issue in the
short term.

> I'd rather use XDG_CACHE_HOME for this as it's already well specified
> and actually not Guile-specific
> (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html).

Setting XDG_CACHE_HOME to the build directory or /tmp in the Guix build
environnement seems fine to me.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: RFC: writable private scratch XDG_CACHE_HOME in build enviroment?

[Andy Wingo]

On Tue 21 Feb 2017 18:50, Mathieu Lirzin <mthl@gnu.org> writes:

> Andy Wingo <wingo@igalia.com> writes:
>
>>> Since /tmp is writeable in a Guix build environment and in most POSIX
>>> systems (I guess), Would it make sense for Guile itself to fallback to
>>> /tmp for its compilation cache?
>>
>> It's possible.  It's a bit gnarly though:
>>
>>   * you get the usual race conditions between users and /tmp that you
>>     have to mitigate
>
> Nothing different from the race conditions for a single user using
> XDG_CACHE_HOME when compilation is done by multiple threads?

Say you are compiling /foo/bar/baz.scm.  Say your XDG_CACHE_HOME is /tmp
and so it would cache to /tmp/foo/bar/baz.go.  You have to make sure
that /tmp/foo, /tmp/bar, and /tmp/bar.baz.go aren't symlinks created by
another user.

Probably having per-user cache directories fixes this problem for the
leaves, though you would still have it when creating the root
/tmp/mthl-guile-cache directory.

> Maybe we could apply the the sane principles of memoization by computing
> the "value" of a file (by hashing it?) and search it in the different
> ".go" stores (GUILE_LOAD_COMPILED_PATH, XDG_CACHE_HOME, site-ccache,
> ...)?
>
> I don't know if the idea is stupid or not, maybe I miss an obvious
> point.  Anyway this doesn't fit the purpose of fixing your issue in the
> short term.

I would love to do this in Guile but I don't know how :)  Procedural
macros make it tricky.  Consider that there are even some macros that
spawn C compilers!  But there are probably good approximations we can
make (e.g. sha256 of files for imported modules assuming that each
module has a single file, an optional hook to include other files).  I
would like this very much though I don't know yet about the details.

>
>> I'd rather use XDG_CACHE_HOME for this as it's already well specified
>> and actually not Guile-specific
>> (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html).
>
> Setting XDG_CACHE_HOME to the build directory or /tmp in the Guix build
> environnement seems fine to me.

OK I'll do this for the next fibers package and see how it goes.  Thanks
for the feedback.

Andy

Re: RFC: writable private scratch XDG_CACHE_HOME in build enviroment?

[Ludovic Courtès]

Hey hey!

Andy Wingo <wingo@igalia.com> skribis:

> Guile will try to automatically compile .scm files and cache them in
> XDG_CACHE_HOME.  When building Guile itself, Guile sets XDG_CACHE_HOME
> to ${top_builddir}/cache.  What if we would set this ourselves for all
> packages?  That way all packages could benefit from a scratch location
> when building that wouldn't propagate to the outputs.

Among all our packages, only one (glib) defines XDG_CACHE_HOME in its
build process.  So I’d rather avoid defining it in gnu-build-system.

> In Fibers I have some tests that I assume get compiled.  If they're not
> compiled, they go quite slow (260s vs 5s).  Alternately I could add a
> XDG_CACHE_HOME setting in Fibers.  Which should we do?

What about changing Fibers to set XDG_CACHE_HOME upon ‘make check’?
This is a good way to ensure that the tests are indeed getting compiled,
and not specifically on Guix.

Cheers,
Ludo’.