Replicable environment with Python packages missing from Guix

[Lasse Schlör]

Hello,

I am in the process of setting up a replicable environment (OS & software 
versions) for a research project using Guix. This includes an installation of 
the Python package PsychoPy.

As far as I understand, the ideal way to do this is to use a `manifest.scm` 
file that includes a `python-psychopy` package together with a `channels.scm` 
to pin/freeze the exact software versions.

Currently, no PsychoPy package exists for Guix, and so I attempted to write my 
own Guix packages for PsychoPy and those of its dependencies that don't exist 
as Guix packages either.

However, while I was able to successfully wrap a few Python packages as Guix 
packages, the number of build and test dependencies turns out to be quite 
large, and I am not sure I have the knowledge and time to write Guix packages 
for all of them.

As a workaround, I have instead written a manifest file that provides a fixed 
version of Python, Pip, and some of PsychoPy's dependencies. I can use this to 
start a container with `guix time-machine […] -- shell --container 
--share=path/to/persistent/.local=/home/username/.local […]`, which has a 
persistent `~/.local` directory, into which the correct version of PsychoPy can 
be installed via `python3 -m pip install -r path/to/requirements.txt`. Making 
`~/.local` persistent allows to start new instances of this container without 
having to re-install PsychoPy every time.

Of course, this doesn't feel as elegant as the purely functional Guix way of 
doing things. I am sure others before me have had similar situations. Thus, my 
question is: Is there a known/preferred/elegant way of creating replicable Guix 
environments with fixed versions of Python packages when these packages do not 
exist as Guix packages?

I'd appreciate any insight on this.

Thanks and best regards,
Lasse Schlör