Re: using an SRFI that is not available in Guile

2022-01-14 Thread Maxime Devos
Attila Lendvai schreef op do 13-01-2022 om 18:20 [+]:
> > Using the guile REPL is a little less complicated than the guix
> > repl,
> > I would recommend trying
> > 
> > "./pre-inst-env guix shell guile-srfi-189 -- guile" first.
> 
> no luck with this either:
> 
> $ ./pre-inst-env guix build guile-srfi-189

I forgot to include "guile" ("guix shell" needs that to know
"GUILE_LOAD{,_COMPILED}_PATH"), try

./pre-inst-env guix shell guile guile-srfi-189 -- guile

instead.


signature.asc
Description: This is a digitally signed message part


Re: Caching The Python World: guix shell --container

2022-01-14 Thread Ricardo Wurmus


jgart  writes:

> Is there currently a convenient way to tell Guix to build "all python-*
> packages" and cache them?

This should do it:

guix build --keep-going -e '\
  (begin \
(import (guix packages) (gnu packages) (guix build-system python)) \
(fold-packages \
  (lambda (item acc) \
(if (eq? python-build-system (package-build-system item)) \
  (cons item acc) acc)) \
  (list)))'

This will build all packages with python-build-system.

-- 
Ricardo



Caching The Python World: guix shell --container

2022-01-14 Thread jgart
Hi Guixers, 

I've been developing an app[0] that launches jupyter notebooks in "the
cloud" in guix containers[1]. In other words, the user submits a url for a
git repo containing the jupyter notebook and the app runs the notebook
in a guix container serving it to the user's browser tab.

The app auto-detects a manifest.scm in the root of the jupyter notebook's
project repository. The app then builds the container and all the
dependencies for the notebook specified by the manifest.scm.

The issue is the following: 

Sometimes a manifest with 10 notebook dependencies or even less will take
a long time (> 3 minutes) for Guix to build the container with everything
specified by the manifest.

For example, this repository containing a guix manifest caused the
browser to timeout out today after minutes of waiting for guix to build
the container.

https://github.com/BonfaceKilz/tsaf-analysis-of-bxd-mouse-colonies/blob/main/manifest.scm

Is there a way to pre-cache all the guix packaged binaries or a
subset thereof *ahead of time* so that if the user needs a particular
package/library they can get it near instantaneously[2]/on demand when
the app calls guix shell?

In other words, I am interested in pre-caching "the python world"
packaged by GNU Guix upstream. 

Is there currently a convenient way to tell Guix to build "all python-*
packages" and cache them? One way that comes to mind is dumping all
the python packages to a manifest and regularly updating that manifest
as new packages are added by maintainers. 

Does this sound like a sane way to solve this container build waiting issue?

Any thoughts/advice is much appreciated.

all best,

jgart

[0]: https://git.genenetwork.org/jgart/binderlite
[1]: https://guix.gnu.org/en/blog/2015/container-provisioning-with-guix/
[2]: https://guix.gnu.org/en/blog/2021/from-guix-environment-to-guix-shell/
"hot cache, in 0.1 seconds"




Re: Celebrating ten years of Guix

2022-01-14 Thread Pjotr Prins
On Wed, Jan 12, 2022 at 03:27:32PM +0100, Ludovic Courtès wrote:
> Hello Guix!
> 
> This year marks the tenth anniversary of Guix; what if we used that as a
> pretext to join forces and organize “special events” throughout the
> year?  Obviously the Guix Days are already a great start!

Great idea. 

In 2014 I watched your first presentation of Guix at FOSDEM. I was
sold on the spot! We use Guix containers and services through all our
deployments - it is a massive success story.

https://guix.gnu.org/guix-fosdem-20140201.pdf

Onwards and upwards!

Pj.



Preparing the 1.4.0 release.

2022-01-14 Thread Mathieu Othacehe


Hello,

As you may know we have started working actively on the next Guix
release.

* The release branch is available here:
  https://git.savannah.gnu.org/cgit/guix.git/log/?h=version-1.4.0
  
* It is built by Cuirass here:
  https://ci.guix.gnu.org/jobset/version-1.4.0

It would be great if we could coordinate and distribute the
effort. We need support to:

* Fix the bugs in this meta issue:
  https://issues.guix.gnu.org/53214

* Check the release machinery is still working by following those steps:
  https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/release.org.
  
* Gather the list of changes between 1.3.0 and 1.4.0 in order to
  complete the NEWS file.

* It is planned to merge the wip-harden-installer branch in the
  version-1.4.0. Once done, we will need some help to test the
  installer.

Who's available to help :) ?

Thanks,

Mathieu