unofficial mirror of guix-science@gnu.org 
 help / color / mirror / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: "Lestang, Thibault" <t.lestang@imperial.ac.uk>
Cc: "Simon Tournier" <zimon.toutoune@gmail.com>,
	"Ludovic Courtès" <ludovic.courtes@inria.fr>,
	guix-science@gnu.org
Subject: Re: Conda environments and reproducibility
Date: Mon, 13 Mar 2023 12:00:17 +0100	[thread overview]
Message-ID: <87r0ts3o8n.fsf@elephly.net> (raw)
In-Reply-To: <LO2P265MB059058CA46ECF928E3322DF2DDB99@LO2P265MB0590.GBRP265.PROD.OUTLOOK.COM>


"Lestang, Thibault" <t.lestang@imperial.ac.uk> writes:

> Ludovic Courtès <ludovic.courtes@inria.fr> writes:
>
>> Any findings so far?  Looking at the pipelines, it seems to be all
>> green, right?
>
> Timely reply - all green until 3 days ago when the job timed out after 70min. 
> However, I re-ran the job manually this morning and it succeeded within a couple of minutes. Not 
> quite sure what happened but probably not related to conda. Not logs available unfortunately.
>
> If the process of reproducing the environment is going to fail at some point, I 
> wonder if we could accelerate this process by defining a more complex environment. 
> Any ideas?

A more complex environment would increase the chance of failure because
it increases the complexity of the challenge to the resolver.  While it
would be a useful demonstration to see the resolver fail I think it is
the least damning kind of failure.

As Simon suggests, changing the underlying system that *currently*
satisfies all the implicit assumptions that Conda artefacts contain
would likely yield a more realistic and interesting kind of failure.

>
> Simon Tournier <zimon.toutoune@gmail.com> writes:
>
>> 1. also use the image continuumio/miniconda3:latest
>> 2. install Miniconda on the top of the Docker image of Debian
>>   unstable and run "apt update && apt upgrade"
>> 
>> And I expect that #2 will break first, then #1 and last the current
>> one.
>
> Could you elaborate on this? For context the current pipeline 
> pulls a pinned miniconda image then updates conda (=conda update conda=).  
> Do you expect system libraries (I mean software installed through apt, not 
> managed by conda) to influence the conda environment creation?  My current 
> understanding is that conda brings its  own copies of these libraries without relying 
> on whatever was/will be installed through other ways (e.g. apt).

This depends on the packages.  There are packages that do link with
system libraries, and these are provided by a base image in which the
binary artefacts are built.

-- 
Ricardo


  reply	other threads:[~2023-03-13 11:06 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28 17:28 Conda environments and reproducibility Thibault Lestang
2022-11-28 19:45 ` Konrad Hinsen
2022-11-29 10:32   ` Thibault Lestang
2022-11-29 13:12     ` Hugo Buddelmeijer
2022-11-29 13:39       ` Konrad Hinsen
2022-12-01 14:01         ` Hugo Buddelmeijer
2022-12-02 13:01           ` Konrad Hinsen
2022-11-29 20:10       ` Simon Tournier
2022-12-16 10:16         ` Thibault Lestang
2023-03-11 11:05           ` Ludovic Courtès
2023-03-11 11:43             ` Simon Tournier
2023-03-13 10:26               ` Lestang, Thibault
2023-03-13 11:00                 ` Ricardo Wurmus [this message]
2023-03-13 12:38                   ` Simon Tournier
2023-03-16 10:26                     ` Ludovic Courtès
2023-03-16 13:40                       ` Thibault Lestang
2023-04-03 15:22                         ` Simon Tournier
2023-04-04 12:19                           ` Thibault Lestang
2022-12-02 10:52       ` Ludovic Courtès
2022-12-02 11:05       ` Ludovic Courtès
2022-12-02 13:59         ` Simon Tournier
2022-12-02 14:06         ` Hugo Buddelmeijer
2022-11-28 20:46 ` Simon Tournier
2022-11-29 10:41   ` Thibault Lestang
2022-11-29 14:25     ` Simon Tournier

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=87r0ts3o8n.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=guix-science@gnu.org \
    --cc=ludovic.courtes@inria.fr \
    --cc=t.lestang@imperial.ac.uk \
    --cc=zimon.toutoune@gmail.com \
    /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.
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).