From: Kyle Andrews <kyle@posteo.net>
To: Simon Tournier <zimon.toutoune@gmail.com>
Cc: help-guix@gnu.org
Subject: Re: Using an alternative python to build python modules
Date: Fri, 24 Feb 2023 00:16:20 +0000 [thread overview]
Message-ID: <87ilfr277g.fsf@posteo.net> (raw)
In-Reply-To: <86pma2t3jd.fsf@gmail.com>
Simon Tournier <zimon.toutoune@gmail.com> writes:
> (I let aside the inferior part that you do not need, IMHO.)
I hope you are right. I will keep thinking about it and will try to
revisit some of my assumptions.
> The computational environment you create with Conda is totally
> inconsistent in regard to the Python version label. The Conda
> resolver works using the version label. Consider this scenario:
>
> A library X version x.y builds with Python interpreter version p.q and
> you are interested by library A depending on library X version x.y and
> also by some Python libraries and the Python interpreter version b.d,
> then library X is not rebuilt with Python interpreter version b.d.
> Somehow, Conda exploits some binary compatibility, roughly what Guix
> names grafts. :-)
>
> Other said, Conda is not building and then serving all the matrix of
> possible combinations. Somehow Conda cheats when Guix not. Well, I am
> not saying that cheating is not practical, instead I think that by using
> this kind of cheat, the reproducibility becomes harder by design because
> it lacks a fine control of the complete DAG.
That makes sense. However, I see scientists using conda as a way to get
up and running quickly with any kind of development environment at all
for the packages that interest them. I just wish there was a low
complexity path to go from that chaos to a reproducible specification
once the scientist has established their proof of concept was a success.
That said, I am very impressed by how much complex scientific software
is already available in Guix. For example, during this email I was going
to make an example of rdkit only to find that it was already
packaged!. I had struggled for a long time to get that installed on
centos7 outside of a conda environment before I became comfortable with
them. Of course, there are still some big gaps in the chemistry
packages, especially for widely used for Density Functional Theory-based
calculations like ABINIT and Quantum Espresso. I suppose it should only
take one person rolling up their sleeves.
=> https://www.abinit.org/
=> https://www.quantum-espresso.org/
> This lead to the other point…
>
>> I'm just wishing that this
>> approach will work in the near future. So, please don't let anyone
>> include it yet :)
>
> …rewrite on the fly the DAG is cheap with Guix but build it is not. :-)
That makes sense.
> I agree that a similar feature as Conda where you can specify the Python
> version and a list of Python library, yeah this feature would help
> people from Conda in convincing them that Guix is more suitable.
> However, for most of the scientific applications I know, the version of
> Python is not really something pertinent – other said, that’s a fun
> feature but useless in practise, IMHO, just a dumb collective practise
> inherited from the poor Python ecosystem, and for sure it does not help
> for reproducing the computational environment (end of my grumbles :-)).
Again, I hope you are right. I really appreciate all your guidance.
prev parent reply other threads:[~2023-02-24 1:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 21:27 Using an alternative python to build python modules Kyle Andrews
2023-02-18 9:57 ` Wojtek Kosior via
2023-02-18 17:53 ` Edouard Klein
2023-02-20 22:29 ` Kyle Andrews
2023-02-21 16:50 ` Edouard Klein
2023-02-21 12:52 ` Simon Tournier
2023-02-21 20:26 ` Kyle Andrews
2023-02-21 21:10 ` Simon Tournier
2023-02-22 9:23 ` Simon Tournier
2023-02-21 21:28 ` Kyle Andrews
2023-02-22 4:23 ` Kyle Andrews
2023-02-22 10:09 ` Simon Tournier
2023-02-24 0:16 ` Kyle Andrews [this message]
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=87ilfr277g.fsf@posteo.net \
--to=kyle@posteo.net \
--cc=help-guix@gnu.org \
--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).