unofficial mirror of guix-science@gnu.org 
 help / color / mirror / Atom feed
From: Thibault Lestang <t.lestang@imperial.ac.uk>
To: guix-science <guix-science@gnu.org>
Subject: Conda environments and reproducibility
Date: Mon, 28 Nov 2022 17:28:48 +0000	[thread overview]
Message-ID: <87pmd7ar8k.fsf@imperial.ac.uk> (raw)

Hi there,

I'm new to the list so apologies if this has already been discussed
before.

I've been ruminating on reproducible builds ever since I attended the 10
years birthday event a few months ago. For me, putting /python/ and
/reproduciblity/ together in the same sentence used to invariablity lead
to /virtualenvs/ or /conda/ being featured in the next - suffice it to
say that part of my world view was shattered a bit (that's okay).

Things progressively start to make sense, but when talking about Guix
with a colleague earlier today it became apparent that my understanding
isn't exacly rock solid yet. Particularly, looking at this tweet

https://twitter.com/luispedrocoelho/status/1087685131144495104

referred to in Ludovic's article "Toward reproducible Jupyter notebooks"
(https://hpc.guix.info/blog/2019/10/towards-reproducible-jupyter-notebooks/).

The tweet says (22 Jan 2019)

-----
@luispedrocoelho
Me, 6 months ago: I am going to save this conda
environment with all the versions of all the packages so it can be
recreated later; this is Reproducible Science!

conda, today: these versions don't work together, lol.
-----

I simply can't explain how such a behavior can happen.

I understand that conda ships pre-compiled binaries. I see how that's
bad for reproducibility and provenance tracking since it's not
straightforward to know how these binaries and dependencies were
compiled. I'm assuming that, when conda saves an environment, it records
version tags and "everything else required" to pull the same binaries
later. Okay - I see how binaries could /technically/ be modified at a
later stage whilst maintaning the same version tag (provenance tracking
issue).

Is it the case that someone at Anaconda would modify some package,
keeping the same version tag and other identifiers used by conda, whilst
at the same time marking this package as incompatible with packages it
was previously compatible with?

Thanks for reading!

Thibault

-- 
Dr Thibault Lestang
Senior Research Software Engineer
Department of Aeronautics, Imperial College London


             reply	other threads:[~2022-11-28 18:15 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28 17:28 Thibault Lestang [this message]
2022-11-28 19:45 ` Conda environments and reproducibility 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
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=87pmd7ar8k.fsf@imperial.ac.uk \
    --to=t.lestang@imperial.ac.uk \
    --cc=guix-science@gnu.org \
    /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).