[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using an alternative python to build python modules

From: Kyle Andrews
Subject: Re: Using an alternative python to build python modules
Date: Fri, 24 Feb 2023 00:16:20 +0000

Simon Tournier <> 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.


> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]