repo2docker
repo2docker copied to clipboard
Add Guix buildpack
Hi! This patch adds a backend that uses the GNU Guix package manager. Guix provides reproducible software environments, transparency and provenance tracking. Coupled with a channels.scm file, it allows users to pin to a specific Guix revision from which the set of packages listed in their manifest.scm is deployed, thereby supporting very fine-grain reproducibility.
Let me know what you think
Thanks for submitting your first pull request! You are awesome! :hugs:
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please make sure you followed the pull request template, as this will help us review your contribution more quickly.
You can meet the other Jovyans by joining our Discourse forum. There is also a intro thread there where you can stop by and say Hi! :wave:
Welcome to the Jupyter community! :tada:
Hi @yuvipanda. I can reply on the Nix vs. Guix bit (I'm a Guix co-maintainer). :-)
Guix and Nix are independent projects with different code bases. The tools are both "functional package managers", which sets them apart from other tools out there; you'll find some of the core concepts are the same, and Guix borrowed them from Nix (Guix's build daemon is based on that of Nix).
Apart from that, the user interfaces are different (in Guix we try hard to make the CLI accessible to non-experts, to offer customization options, and to provide good integration for a variety of software deployment tools), the packages they provide are different (e.g., Guix insists on free software built from source as a way to improve transparency and security), and so on.
There's a growing scientific computing community around Guix with a focus on high-performance computing (HPC) and reproducible science. I'm confident there'll be interest in keeping Guix support afloat in repo2docker.
Let me know if you need more info!
@civodul Thank you for your explanations - that sounds good enough to me. Let's working on getting stuff outside of $HOME and work towards getting this deployed! \o/
If you rebase your PR, it should also fix the failing docker build and build docs as well.
Thanks for your feedback @yuvipanda, what do you think now ?
Thanks for addressing these, @hulecomte! I still haven't managed to test this locally, but hope this is all still useful.
To respond to #1048 (comment), IMO we shouldn't hand-move things installed with another package manager (in this case, apt). If you try to use apt to remove it, I'm sure it'll take a bunch of other packages with it. IMO, this means we shouldn't try to do that, since it will just silently break other things. We already do this with nix, conda, etc - IMO that's what we should do here too.
When the container runs and the user tries to do
pip install numpy
, it should automatically use the 'correct' python installed - in this case, the guix one. For example, in the conda buildpack (https://github.com/jupyterhub/repo2docker/blob/f07111c4a58220263562f726fb55288da57fe71f/repo2docker/buildpacks/conda/init.py#L54 ), just the
PATH
is enough to 'do the right thing'. And/usr/bin/python3
is never used.Let's try do the same here?
Thanks for working with me through this!
Hey yuvipanda! I'm currently trying that but it seems I still can use python while using bash script to test the buildpack...Maybe I am not doing it well enough? What do you think ?
Anyway, I don't now why lint test is failing and I don't know how it works too. How can I reproduce it locally ?
Thanks!
Hey @yuvipanda here are some updates: -I modified the doc and the guix-install.bash as you suggested. -Added a PATH 'do to the right thing' as we discussed it previously.
What do you think?
Hi @yuvipanda & all! Would be great if @hulecomte's work could get in. :-)
Is there anything left that you think we should do?
Thanks in advance!
Hi @yuvipanda, could you take another look at this PR?
Thanks in advance.
I'm very excited about this addition. Are there any other obstacles to getting this merged?
Hi! Any update here?