Simon Tournier writes:
> Hi,
>
>
> On Sun, 26 Feb 2023 at 16:52, Kyle wrote:
>
>> One idea might be to write a conda importer which looks at the
>> versions of software in the resulting environment and tries to make
>> feasible package variants of make a manifest which matches the
>> existing conda environment as close as possible.
>
> Do you mean, from ’conda env export’ Which outputs something like,
>
> name: justnumpy
> channels:
> - defaults
> dependencies:
> - _libgcc_mutex=0.1=main
> - _openmp_mutex=5.1=1_gnu
> - blas=1.0=mkl
> - libuuid=1.41.5=h5eee18b_0
> - mkl=2021.4.0=h06a4308_640
> - mkl-service=2.4.0=py310h7f8727e_0
> - mkl_fft=1.3.1=py310hd6ae3a3_0
> - mkl_random=1.2.2=py310h00e6091_0
> - ncurses=6.3=h5eee18b_3
> - numpy=1.23.4=py310hd5efca6_0
> - numpy-base=1.23.4=py310h8e6c178_0
> - ...
> - ...
>
> transform this into some Guix manifest.scm? Well, indeed, it could help
> people for transitioning.
Yes, exactly. Parse the output of this command and generate a bunch of
definitions for a manifest file but which might also be upstreamed to
the guix-past repository.
>> Another idea would be to create a python package for working with Guix
>> more directly from inside their preferred language environment instead
>> of through the shell. I also wouldn't mind it if such a thing existed
>> for R as well.
>
> Do you mean ’guix.install()’ from r-guix-install?
>
> https://cran.rstudio.com/web/packages/guix.install/index.html
>
> How do you install Python packages from the Python REPL?
With the reticulate package in R, a python environment can be readily
instantiated using R code like `use_condaenv`.
https://rstudio.github.io/reticulate/articles/versions.html
In my dreams there would be a `use_guix()` command as well. Of course,
right now that R code is limited to setting up python-specific
environments and conda environments (and installing python packages into
them). However, it still might be valuable to get the name recognition
for Guix in this limited context.
While guix would be responsible for just the python environment in the
context of the reticulate package, that isn't the only possible use
case. It would be nice to write that integration for reticulate by
having them use another R package with deeper integrations built out for
managing guix itself from R. That's why I brought up RcppGuile as a path
for how R could interface directly with the Guix scheme libraries. Such
an interface might be useful for other interactive scientific
environments like python as well. The goal would be to make Guix seem
less exotic to researchers in typical scientific languages. If it's part
of their "home" computing environment, then they might be much more
interested in trying it out. This reflects a bigger scope than just
being a replacement for install.packages.
> Cheers,
> simon
>
> PS:
>
>> Simon thought often
>> the python version usually didn't matter, but it makes users a lot
>> less woosy to stick with software combinations they have already
>> tested.
>
> This is out of context. :-) For the context, see [1].
Thanks for the point of clarification. Sorry, I didn't add the reference
in my initial message.
> Well, if you have only one Python version, you only test against this
> one, so being able to combine on the fly the matrix of Python versions
> is not so much important – it is a collective practise inherited from
> the “unstable” Python ecosystem and I am doubtful about its relevancy
> concerning referencing software for reproducing. Now Conda is more than
> 10 years and very very broadly used, so if its specification using
> version labels and relying on some matrix of Python versions would be
> enough for reproducibility, then I would have never landed in Guix. ;-)
>
> 1: https://yhetil.org/guix/86pma2t3jd@gmail.com
>
> My 2 cents. :-)
Later in that conversation you made the point that the purpose of the
guix-past channel was to make things like this possible. I added my
voice to this (GSOC Project) thread because I thought it would be useful
to place a fresh pair of eyes at tackling the combinatorial
configuration problems which still stand in the way of curating a large
Guix package repository with the breadth of scientific package versions
that a platform like conda provides... even if it cheats a lot by not
doing that reproducibly. Whatever they learn might also help elsewhere
in the project, such as potentially helping to curate large collections
of packages in other languages like those in Go, Rust, or even
JavaScript.
