Guix mentioned in Journal of Open Source Software (JOSS)

Guix mentioned in Journal of Open Source Software (JOSS)

[Pjotr Prins]

We published a paper on GeneNetwork which uses Guix for deployment:

  http://joss.theoj.org/papers/10.21105/joss.00025

The review process is online and you can see there were some hickups
with Guix:

  https://github.com/openjournals/joss-reviews/issues/25

(1) Roel has suggested we should script the binary installation. I think
that is a fine idea. That was hurdle one.

(2) Hurdle two is fixating the package tree. I would really like a 

  git pull --version HASH

where HASH pulls a git HASH version of the gnu/packages tree and
compile the scheme files. That would help binary reproducibility
without having to check out the full tree.

We don't need to roll-back the guix client, though that would be nice
too and should be possible with Guix. Just give it a different binary
name, how about guix-HASH? When using guix-HASH it would automatically
use the older guix and the older package tree.

Or something along that vein.

(3) I also think the default GUIX key should just be available. Why make
guix authorize an extra step? When I install guix, I WANT it.

(4) Finally, is there a way to automatically inject the search paths in
the shell? Rather than printing them, and people have to copy-paste,
why not create a new shell with paths set? Or is that already
available?

Addressing these 4 points and Guix install should be a breeze ;). Even
with an external package path.

Pj.

Re: Guix mentioned in Journal of Open Source Software (JOSS)

[Ricardo Wurmus]

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> (4) Finally, is there a way to automatically inject the search paths in
> the shell? Rather than printing them, and people have to copy-paste,
> why not create a new shell with paths set? Or is that already
> available?

At this institute I recommend users install software into one profile
per project.  To “enter” a profile users do this:

    bash
    cd projects/world-peace
    source .guix-profile/etc/profile
    # variables are set now
    # do work here
    exit

They enter a subshell, then go to their project directory in which they
have a Guix profile (always named “.guix-profile”).  By sourcing the
profile’s “etc/profile” all environment variables are set up.

When they are done they just exit the subshell, thereby restoring the
environment to its previous state.

~~ Ricardo

Re: Guix mentioned in Journal of Open Source Software (JOSS)

[Alex Kost]

Pjotr Prins (2016-06-14 10:47 +0300) wrote:

> We published a paper on GeneNetwork which uses Guix for deployment:
>
>   http://joss.theoj.org/papers/10.21105/joss.00025
>
> The review process is online and you can see there were some hickups
> with Guix:
>
>   https://github.com/openjournals/joss-reviews/issues/25
>
> (1) Roel has suggested we should script the binary installation. I think
> that is a fine idea. That was hurdle one.
>
> (2) Hurdle two is fixating the package tree. I would really like a 
>
>   git pull --version HASH
    guix pull --version HASH
    ^^^^
I guess a typo

> where HASH pulls a git HASH version of the gnu/packages tree and
> compile the scheme files. That would help binary reproducibility
> without having to check out the full tree.
>
> We don't need to roll-back the guix client, though that would be nice
> too and should be possible with Guix. Just give it a different binary
> name, how about guix-HASH? When using guix-HASH it would automatically
> use the older guix and the older package tree.
>
> Or something along that vein.
>
> (3) I also think the default GUIX key should just be available. Why make
> guix authorize an extra step? When I install guix, I WANT it.
>
> (4) Finally, is there a way to automatically inject the search paths in
> the shell? Rather than printing them, and people have to copy-paste,
> why not create a new shell with paths set? Or is that already
> available?

Are you looking for "guix package --search-paths=prefix"?

-- 
Alex

Re: Guix mentioned in Journal of Open Source Software (JOSS)

[Ricardo Wurmus]

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> We published a paper on GeneNetwork which uses Guix for deployment:
>
>   http://joss.theoj.org/papers/10.21105/joss.00025

Congratulations on getting the paper accepted!

> The review process is online and you can see there were some hickups
> with Guix:
>
>   https://github.com/openjournals/joss-reviews/issues/25

It’s good that this was documented.

> (1) Roel has suggested we should script the binary installation. I think
> that is a fine idea. That was hurdle one.
>
> (2) Hurdle two is fixating the package tree. I would really like a 
>
>   git pull --version HASH

“guix” or “git”?

> where HASH pulls a git HASH version of the gnu/packages tree and
> compile the scheme files. That would help binary reproducibility
> without having to check out the full tree.

What is the problem with checking out the “full tree”?  The biggest part
of Guix is the packages tree and it’s using things that are defined in
the smaller part, so they are tightly coupled.

Currently, the easiest way to get to a previous version is to do

    git reset --hard cabba9e

where “cabba9e” is the hash of the version you want to have.  For the
central installation of Guix here at the MDC I suggest people publish
the result of these two commands along with their package manifests:

    git -C /gnu/remote/guix        describe
    git -C /gnu/remote/guix-bimsb  describe

This gives them two hash-like strings for the unmodified Guix upstream
repo and our local repository.  Others trying to reproduce our state
would just need to clone the two repos and reset them to the given
description strings.

> We don't need to roll-back the guix client, though that would be nice
> too and should be possible with Guix. Just give it a different binary
> name, how about guix-HASH? When using guix-HASH it would automatically
> use the older guix and the older package tree.

Since they are coupled “git reset --hard ...” already does this.  But I
agree that it would be nice to have more than one installation of Guix
that allows users to switch versions without having to deal with the git
user interface.

> Or something along that vein.
>
> (3) I also think the default GUIX key should just be available. Why make
> guix authorize an extra step? When I install guix, I WANT it.

What default key do you mean?  Looking at the review I see that this is
about your caching server’s public key, is it not?  In that case I think
having to authorize an external provider of binaries is a feature.
Hydra, I think, is authorized by default.

~~ Ricardo

Re: Guix mentioned in Journal of Open Source Software (JOSS)

[Ludovic Courtès]

Howdy!

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> skribis:

> Pjotr Prins <pjotr.public12@thebird.nl> writes:
>
>> We published a paper on GeneNetwork which uses Guix for deployment:
>>
>>   http://joss.theoj.org/papers/10.21105/joss.00025
>
> Congratulations on getting the paper accepted!

Indeed, well done!

>> (1) Roel has suggested we should script the binary installation. I think
>> that is a fine idea. That was hurdle one.
>>
>> (2) Hurdle two is fixating the package tree. I would really like a 
>>
>>   git pull --version HASH
>
> “guix” or “git”?

I think ‘guix’, but eventually it’ll be almost the same:

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22629

I think the plan outlined in this bug report should address your
concerns, Pjotr, and I agree it’d be very useful.

>> (3) I also think the default GUIX key should just be available. Why make
>> guix authorize an extra step? When I install guix, I WANT it.
>
> What default key do you mean?

For substitutes.

Maybe the 7 steps described under “Binary Installation” should be
replaced by a shell script that would be added in the binary tarball?
Hopefully it would be below 20 lines and people could easily check what
it does.

That script could also add the hydra.gnu.org key to the ACL.

Thoughts?

Ludo’.

Re: Guix mentioned in Journal of Open Source Software (JOSS)

[Andy Wingo]

On Tue 14 Jun 2016 09:47, Pjotr Prins <pjotr.public12@thebird.nl> writes:

> (3) I also think the default GUIX key should just be available. Why make
> guix authorize an extra step? When I install guix, I WANT it.

I agree.  If you are installing from a binary snapshot, you are trusting
binaries now.  Trusting binaries in the future is not the same but very
similar and almost always what the user wants.  The minority of users
that prefer a different source of binaries in the future can set this up
themselves.

Andy