unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludovic.courtes@inria.fr>
To: Konrad Hinsen <konrad.hinsen@cnrs.fr>
Cc: guix-devel <guix-devel@gnu.org>, guix-hpc@gnu.org
Subject: Re: “Reproducible research articles, from source code to PDF”
Date: Thu, 18 Jun 2020 13:42:14 +0200	[thread overview]
Message-ID: <87r1ucmwh5.fsf@inria.fr> (raw)
In-Reply-To: <m1a710g1ea.fsf@fastmail.net> (Konrad Hinsen's message of "Thu, 18 Jun 2020 11:37:49 +0200")

Hi,

Konrad Hinsen <konrad.hinsen@cnrs.fr> skribis:

>> I don’t like the phrase “average scientist”, and we’re talking about
>> people with a PhD who definitely know how to learn.
>
> I didn't take that phrase as a reference to ability, but to prior
> knowledge. I am pretty sure that anyone who uses Python can also learn
> to use Guile, but a computer scientist having experience with ten
> languages will have less effort to do so than an archaeologist or a
> wetlab biologist who has never used anything else but Python.

Yes, I understand and agree with this assessment: making the tools
usable without being an expert will be crucial.

That said, these same people got used to Dockerfiles, CONDA, pip,
Jupyter, CWL, Python, Bash, and whatnot.  I think that stating that all
this, taken together, has a “smooth learning curve”, is inaccurate.

>> Apart from that, I agree with the comments above: putting it in the
>> hands of scientists will be the real challenge.  I think providing
>> modules and ready-to-use “templates” for people who use R+RMarkdown, or
>> LaTeX, or Jupyter, etc. is a necessary step.
>
> I'd start somewhat differently: generate diverse use case examples.  The
> contributions to the ReScience reproducibility challenge could be a nice
> starting point: go through them, one by one, and try to re-implement the
> authors' various approaches with Guix.  Then, in a second step, try to
> identify additional tooling support in Guix that would make the recipes
> simpler to implement. That might well lead to the development of ready
> to use templates, but I prefer starting from a use case analysis to see
> what is needed in real life.

Yes, sounds like a good plan!

> Another obstacle to adoption is the difficulty of deployment. Right now,
> if I use Guix to make my work reproducible, I require my readers to
> install Guix on their computers, which is a lot of work for Linux users
> and a major headache for Windows/macOS users. We really need to reduce
> that barrier to deployment.

On Debian and derivatives, it should be possible to run “apt-get install
guix” soonish, which should help.

For Windows and macOS, I don’t know (I’m personally less interested in
that but I agree it would be useful to improve the situation there.)

> Some ideas: Simple deployment of a VM running Guix System on a major
> cloud provider would be nice to have. Or a service like mybinder.org,
> but based on Guix rather than Docker. Or, for local execution, a Docker
> image containing Guix plus some tooling to do the equivalent of "guix
> time-machine –commit=xxx – build -f guix.scm" plus copying the contents
> of the generated package into the user's directory.

Yes, we should discuss individual solutions along these lines.

Thanks,
Ludo’.


  reply	other threads:[~2020-06-18 11:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-16 12:25 “Reproducible research articles, from source code to PDF” Ludovic Courtès
2020-06-17  7:06 ` zimoun
2020-06-18  7:31   ` Ludovic Courtès
2020-06-18  9:37     ` Konrad Hinsen
2020-06-18 11:42       ` Ludovic Courtès [this message]
2020-06-18 12:56         ` zimoun
2020-06-18 13:05           ` Ludovic Courtès
2020-06-18 16:28             ` Konrad Hinsen
2020-06-19 12:04               ` Ludovic Courtès
2020-06-19 12:14                 ` zimoun
2020-06-19 13:21                   ` Ludovic Courtès
2020-06-21 14:50               ` Konrad Hinsen
2020-06-22  7:38                 ` Ludovic Courtès
2020-06-18 16:39             ` Pjotr Prins
2020-06-18  2:33 ` Maxim Cournoyer

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=87r1ucmwh5.fsf@inria.fr \
    --to=ludovic.courtes@inria.fr \
    --cc=guix-devel@gnu.org \
    --cc=guix-hpc@gnu.org \
    --cc=konrad.hinsen@cnrs.fr \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).