Guix beyond 1.0: let’s have a roadmap!

Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

Hello Guix!

People rightfully suggested having some sort of a roadmap for what’s
next.  Many of us certainly have specific ideas in mind, but having that
written down can certainly clarify what this project is about to
newcomers, and it can help us insiders build a common understanding of
what it is we want to do.

To start the discussion, here’s a list of high-level to-do items, some
of them just copied from our ‘1.0.org’ document :-) and others that stem
from discussions we’ve had.  I’m happy to expound on some of these
points if anything is unclear.

What do *you* want Guix to address in the future?

Ludo’.


[-- Attachment #2: the roadmap --]
[-- Type: text/plain, Size: 2067 bytes --]

#+TITLE: GNU Guix Beyond 1.0—A Road Map

* ‘guix pull’

** TODO 'guix pull' & commit authentication <https://bugs.gnu.org/22883>
** TODO build-self.scm trampoline runs faster

* UI/UX

** TODO grafts and profile hooks run as “build continuations” <https://bugs.gnu.org/28310>
** TODO ‘package-derivation’ made faster
** TODO (gnu installer) UI can be used to edit config.scm
** TODO ‘guix system status’ shows info about the current status

* core

** TODO substitutes can be published and fetched over IPFS <https://issues.guix.gnu.org/issue/33899>
** TODO ‘wip-build-systems-gexp’ branch updated & merged
** TODO labels removed from the inputs fields of packages
** TODO [[https://gitlab.com/rutger.van.beusekom/gash][Gash]] used instead of Bash during bootstrap
** TODO Guix System can run GNU/Hurd
** TODO shepherd uses Fibers, logs correctly, can do “socket activation”
** TODO (guix record) provides optional static type checking

* build daemon

** TODO daemon rewritten in Scheme
** TODO daemon supports “recursive derivations”
** TODO daemon supports more hash algorithms
** TODO daemon stores zero or more narinfo signatures per store item

* devops

** TODO ‘guix system reconfigure --target=host.example.org’ is a thing
** TODO ‘guix deploy’ is a thing

* miscellaneous

** TODO ‘static-networking-service’ supports IPv6
** TODO Debian package for Guix is available
** TODO ‘--with-least-authority’ package transformation + ‘guix run’ added
** TODO GNOME Software backend written
** TODO GTK+ can use Guix “powerbox” instead of Flatpak’s

* infrastructure

** TODO web site officially available at https://guix.gnu.org
** TODO web site includes a package and service browser
** TODO Guix Data Service deployed
** TODO code and services shared between Guix Data Service and Cuirass
** TODO package sources are always archived on Software Heritage
** TODO web site translated in other languages
** TODO official channel registry service available

Re: Guix beyond 1.0: let’s have a roadmap!

[P]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, June 27, 2019 6:05 PM, Ludovic Courtès <ludo@gnu.org> wrote:

> What do you want Guix to address in the future?

System upgrades are still incredibly slow even with a small number of packages, there definitely needs to be more build servers and a way to tell `guix package -u` to wait for substitutes to become available.

Package search is kind of bad compared to Arch's pacman.

An alternative to pkgfile would also be nice for knowing which package has a certain file.

Just, speed... in general. Guix pull takes so long to compile things.

[-- Attachment #2: ROADMAP.org --]
[-- Type: text/plain, Size: 2014 bytes --]

#+TITLE: GNU Guix Beyond 1.0—A Road Map

* ‘guix pull’

** TODO 'guix pull' & commit authentication <https://bugs.gnu.org/22883>
** TODO build-self.scm trampoline runs faster

* UI/UX

** TODO grafts and profile hooks run as “build continuations” <https://bugs.gnu.org/28310>
** TODO ‘package-derivation’ made faster
** TODO (gnu installer) UI can be used to edit config.scm
** TODO ‘guix system status’ shows info about the current status

* core

** TODO substitutes can be published and fetched over IPFS <https://issues.guix.gnu.org/issue/33899>
** TODO ‘wip-build-systems-gexp’ branch updated & merged
** TODO labels removed from the inputs fields of packages
** TODO [[https://gitlab.com/rutger.van.beusekom/gash][Gash]] used instead of Bash during bootstrap
** TODO Guix System can run GNU/Hurd
** TODO shepherd uses Fibers, logs correctly, can do “socket activation”
** TODO (guix record) provides optional static type checking

* build daemon

** TODO daemon rewritten in Scheme
** TODO daemon supports “recursive derivations”
** TODO daemon supports more hash algorithms
** TODO daemon stores zero or more narinfo signatures per store item

* devops

** TODO ‘guix system reconfigure --target=host.example.org’ is a thing
** TODO ‘guix deploy’ is a thing

* miscellaneous

** TODO ‘static-networking-service’ supports IPv6
** TODO Debian package for Guix is available
** TODO ‘--with-least-authority’ package transformation + ‘guix run’ added
** TODO GNOME Software backend written
** TODO GTK+ can use Guix “powerbox” instead of Flatpak’s

* infrastructure

** TODO web site officially available at https://guix.gnu.org
** TODO web site includes a package and service browser
** TODO Guix Data Service deployed
** TODO code and services shared between Guix Data Service and Cuirass
** TODO package sources are always archived on Software Heritage
** TODO web site translated in other languages
** TODO official channel registry service available

Re: Guix beyond 1.0: let’s have a roadmap!

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

On 2019-06-27, Ludovic Courtès wrote:
> People rightfully suggested having some sort of a roadmap for what’s
> next.
...
> What do *you* want Guix to address in the future?

A few architecture support issues come to mind:

* Architectures

** TODO system/installer images for armhf
** TODO system/installer images for aarch64
** TODO riscv64 support
** TODO ppc64el(le?)/power9 support

(maybe move GNU/Hurd to this category too?)


> * core
...
> ** TODO [[https://gitlab.com/rutger.van.beusekom/gash][Gash]] used instead of Bash during bootstrap

What about a full bootstrap using MES and company?


> * miscellaneous
...
> ** TODO Debian package for Guix is available

Working on it! kind of stalled out at the moment waiting on processes
within Debian... once the current release is done (scheduled for early
July), things will hopefully start moving again.


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Guix beyond 1.0: let’s have a roadmap!

[Jakob L. Kreuze]

[-- Attachment #1: Type: text/plain, Size: 312 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> What do *you* want Guix to address in the future?

Is there room for parameterized packages? À la Gentoo's USE flags?

> ** TODO ‘guix system reconfigure --target=host.example.org’ is a thing
> ** TODO ‘guix deploy’ is a thing

:)

Regards,
Jakob

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Guix beyond 1.0: let’s have a roadmap!

[Alex Griffin]

On Thu, Jun 27, 2019, at 4:31 PM, Ludovic Courtès wrote:
> What do *you* want Guix to address in the future?

* Guix System

** TODO add firewall-service to provide a configurable stateful firewall suitable for most desktops and servers
*** TODO add service-extensions to existing services so that firewall-service can be added to %base-services without unnecessary breakage

** TODO use guile-bash to automatically update environment variables when the current profile changes

** TODO support more partitioning and bootloader configurations (full disk encryption without entering password twice, LVM support, os-prober, etc.)
*** TODO support secured boot from Heads/PureBoot (https://docs.puri.sm/PureBoot.html)

** TODO easier loading of out-of-tree kernel modules

** TODO run-time configuration system for services, similar to OpenWrt's UCI


* Command Line Interface

** TODO refresh able to take a contributor name and find out-of-date packages that they have contributed to

** TODO improved search: support AND terms instead of OR, configurable recfmt template

** TODO package --show should allow multiple arguments and not require an equal sign


* Other

** TODO evaluate shepherd service definitions placed somewhere in ~/.guix-profile before evaluating ~/.config/shepherd/init.scm

** TODO support automatic GPG/signify signature verification of origin objects

** TODO better Node.js packaging and tooling
*** TODO package important Icecat and Ungoogled-Chromium extensions. This is a pain point because IceCat steers users away from Firefox Add-ons and Ungoogled-Chromium completely disallows installing from Chrome Web Store.


-- 
Alex Griffin

Re: Guix beyond 1.0: let’s have a roadmap!

[Svante Signell]

On Thu, 2019-06-27 at 18:05 +0200, Ludovic Courtès wrote:
> Hello Guix!
> 
> People rightfully suggested having some sort of a roadmap for what’s
> next.  Many of us certainly have specific ideas in mind, but having
> that written down can certainly clarify what this project is about to
> newcomers, and it can help us insiders build a common understanding
> of what it is we want to do.
> 
> To start the discussion, here’s a list of high-level to-do items,
> some of them just copied from our ‘1.0.org’ document :-) and others
> that stem from discussions we’ve had.  I’m happy to expound on some
> of these points if anything is unclear.
> 
> What do *you* want Guix to address in the future?

Hello,

Are you interested in a buildd (in the context of Debian)? I'm
currently hosting the mahler Debian buildd VM for GNU/Hurd and kamp
Debian buildd VM for kFreeBSD amd64 and i386. The first box (mahler) is
reasonably fast and has excellent bandwidth 100Mbps download
speed/800++Mbps upload speed. The other box (kamp) is much faster but
is limited to 10Mbps down/1Mbps up. (We will eventually get a fiber
connection (100Mbps up+down), but the install and operating date is
still unknown.)

Thanks!

Re: Guix beyond 1.0: let’s have a roadmap!

[Thompson, David]

On Thu, Jun 27, 2019 at 12:31 PM Ludovic Courtès <ludo@gnu.org> wrote:
>
> What do *you* want Guix to address in the future?

* Extend 'guix environment' to cover use-cases that people currently
use docker-compose for
* Improve UX of 'guix environment' by using sane defaults and
conventions such as reading from 'guix.scm' file in current directory
* Add a small-scale, general-purpose, "serverless" computing
environment a la AWS Lambda using g-expressions + call-with-container
+ a web server
* Improve portable application bundles so that only files needed at
runtime (no headers, docs, etc.) are included somehow (not sure how to
do this one)
* Allow system services to run unprivileged (perhaps via user
namespaces) so that each user may have their own shepherd instance
(would be useful for other features, too, such as the first item in
this list)

That's all I've got for now. :)

- Dave

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

Hi P,

P <pronaip@protonmail.com> skribis:

> System upgrades are still incredibly slow even with a small number of packages, there definitely needs to be more build servers and a way to tell `guix package -u` to wait for substitutes to become available.
>
> Package search is kind of bad compared to Arch's pacman.
>
> An alternative to pkgfile would also be nice for knowing which package has a certain file.
>
> Just, speed... in general. Guix pull takes so long to compile things.

Agreed on all points… except perhaps for ‘guix search’ which I think got
better just today.  :-)

  https://issues.guix.gnu.org/issue/36390

‘guix pull’ ideally doesn’t compile things and gets substitutes instead,
but it’s still very slow indeed.  Part of that is an issue with Guile’s
compiler.  Another part of it is the “Computing Guix derivation” bit,
which takes a bit less than a minute; this one could benefit from the
“recursive derivation” thing I listed (aka. “recursive Nix”).

Thanks,
Ludo’.

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

Hello,

Vagrant Cascadian <vagrant@debian.org> skribis:

> On 2019-06-27, Ludovic Courtès wrote:
>> People rightfully suggested having some sort of a roadmap for what’s
>> next.
> ...
>> What do *you* want Guix to address in the future?
>
> A few architecture support issues come to mind:
>
> * Architectures
>
> ** TODO system/installer images for armhf
> ** TODO system/installer images for aarch64
> ** TODO riscv64 support
> ** TODO ppc64el(le?)/power9 support
>
> (maybe move GNU/Hurd to this category too?)

Sounds good to me!

>> * core
> ...
>> ** TODO [[https://gitlab.com/rutger.van.beusekom/gash][Gash]] used instead of Bash during bootstrap
>
> What about a full bootstrap using MES and company?

It’s already in ‘core-updates’ so I consider it “done”, at least for
this initial variant.  But yeah, I expect there’ll be incremental
improvements that will allow us to gradually reduce the set of bootstrap
binaries, and also more architecture support (I know people have worked
on ARM support recently.)

>> * miscellaneous
> ...
>> ** TODO Debian package for Guix is available
>
> Working on it! kind of stalled out at the moment waiting on processes
> within Debian... once the current release is done (scheduled for early
> July), things will hopefully start moving again.

Yay!  \o/

Ludo’.

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

zerodaysfordays@sdf.lonestar.org (Jakob L. Kreuze) skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> What do *you* want Guix to address in the future?
>
> Is there room for parameterized packages? À la Gentoo's USE flags?

Sounds good to me!  I’ve added it to my local copy.

Ludo’.

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

Hi Svante,

Svante Signell <svante.signell@gmail.com> skribis:

> Are you interested in a buildd (in the context of Debian)? I'm
> currently hosting the mahler Debian buildd VM for GNU/Hurd and kamp
> Debian buildd VM for kFreeBSD amd64 and i386. The first box (mahler) is
> reasonably fast and has excellent bandwidth 100Mbps download
> speed/800++Mbps upload speed. The other box (kamp) is much faster but
> is limited to 10Mbps down/1Mbps up. (We will eventually get a fiber
> connection (100Mbps up+down), but the install and operating date is
> still unknown.)

Maybe, we’ll see; thanks for offering this!

As a first step, a good option might be to boot a GNU/Hurd image
cross-built with Guix, as I had done with Nix¹.

Ludo’.

¹ https://lists.gnu.org/archive/html/bug-hurd/2011-11/msg00042.html

Re: Guix beyond 1.0: let’s have a roadmap!

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 250 bytes --]

- A graphical install and interface to package management
(GTK or something else graphical).

- Finally fix TeXlive... :p

- User services (That's more of a Shepherd thing, but Guix is involved.)

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Guix beyond 1.0: let’s have a roadmap!

[Julien Lepiller]

Le 27 juin 2019 18:05:27 GMT+02:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :
>Hello Guix!
>
>People rightfully suggested having some sort of a roadmap for what’s
>next.  Many of us certainly have specific ideas in mind, but having
>that
>written down can certainly clarify what this project is about to
>newcomers, and it can help us insiders build a common understanding of
>what it is we want to do.
>
>To start the discussion, here’s a list of high-level to-do items, some
>of them just copied from our ‘1.0.org’ document :-) and others that
>stem
>from discussions we’ve had.  I’m happy to expound on some of these
>points if anything is unclear.
>
>What do *you* want Guix to address in the future?
>
>Ludo’.

* accessible installer and installed system
* use the intensional model described in Eelco's thesis (should reduce our computing needs)
* channel browser (along with package and services)

Re: Guix beyond 1.0: let’s have a roadmap!

[swedebugia]

On 2019-06-27 21:02, Alex Griffin wrote:
> On Thu, Jun 27, 2019, at 4:31 PM, Ludovic Courtès wrote:
>> What do *you* want Guix to address in the future?
> 
> * Guix System
> 
> ** TODO add firewall-service to provide a configurable stateful firewall suitable for most desktops and servers

+1

> *** TODO add service-extensions to existing services so that firewall-service can be added to %base-services without unnecessary breakage
> 
> ** TODO use guile-bash to automatically update environment variables when the current profile changes
> 
> ** TODO support more partitioning and bootloader configurations (full disk encryption without entering password twice, LVM support, os-prober, etc.)
> *** TODO support secured boot from Heads/PureBoot (https://docs.puri.sm/PureBoot.html)
> 
> ** TODO easier loading of out-of-tree kernel modules
> 
> ** TODO run-time configuration system for services, similar to OpenWrt's UCI
> 
> 
> * Command Line Interface
> 
> ** TODO refresh able to take a contributor name and find out-of-date packages that they have contributed to
> 
> ** TODO improved search: support AND terms instead of OR, configurable recfmt template
> 
> ** TODO package --show should allow multiple arguments and not require an equal sign

+1

> 
> 
> * Other
> 
> ** TODO evaluate shepherd service definitions placed somewhere in ~/.guix-profile before evaluating ~/.config/shepherd/init.scm
> 
> ** TODO support automatic GPG/signify signature verification of origin objects
> 
> ** TODO better Node.js packaging and tooling

This seem to have gotten stuck. But I heard something about a 
guile-semver and also we need to handle circular dependencies better in 
guix to make it easier to discover and mitigate them.

Compared to the whole expat/JS community Guix is still a very small 
project. The bootstrap problems will probably take years to complete 
with the current pace/manpower/interest.

Maybe we should propose The GNU Project to create and seek funding for a 
"fix JS (bootstrap)" campaign? Compilers will need to be written 
according to Julien (like rustc).

> *** TODO package important Icecat and Ungoogled-Chromium extensions. This is a pain point because IceCat steers users away from Firefox Add-ons and Ungoogled-Chromium completely disallows installing from Chrome Web Store.

Actually currently our Chrome does not support add-ons at all. See bug 
#35709

-- 
Cheers Swedebugia

bug#35709: Guix beyond 1.0: let’s have a roadmap!

[Alex Griffin]

On Thu, Jun 27, 2019, at 10:34 PM, swedebugia wrote:
> > *** TODO package important Icecat and Ungoogled-Chromium extensions. This is a pain point because IceCat steers users away from Firefox Add-ons and Ungoogled-Chromium completely disallows installing from Chrome Web Store.
> 
> Actually currently our Chrome does not support add-ons at all. See bug 
> #35709

I noticed I can use add-ons by installing or updating them with Debian's Chromium and then opening my profile with ungoogled-chromium from Guix. I'd also be surprised if this method of running unpacked extensions didn't work, although I haven't tried it yet: https://github.com/gorhill/uBlock/tree/master/dist#chromium

-- 
Alex Griffin

Re: Guix beyond 1.0: let’s have a roadmap!

[Julien Lepiller]

Le 28 juin 2019 00:33:12 GMT+02:00, swedebugia <swedebugia@riseup.net> a écrit :
>On 2019-06-27 21:02, Alex Griffin wrote:
>> 
>> ** TODO better Node.js packaging and tooling
>
>This seem to have gotten stuck. But I heard something about a 
>guile-semver and also we need to handle circular dependencies better in
>
>guix to make it easier to discover and mitigate them.
>
>Compared to the whole expat/JS community Guix is still a very small 
>project. The bootstrap problems will probably take years to complete 
>with the current pace/manpower/interest.
>
>Maybe we should propose The GNU Project to create and seek funding for
>a 
>"fix JS (bootstrap)" campaign? Compilers will need to be written 
>according to Julien (like rustc).

We're good with nust now :). A big issue is coffeescript and probably most of the languages that compile to javascript.

>
>> *** TODO package important Icecat and Ungoogled-Chromium extensions.
>This is a pain point because IceCat steers users away from Firefox
>Add-ons and Ungoogled-Chromium completely disallows installing from
>Chrome Web Store.
>
>Actually currently our Chrome does not support add-ons at all. See bug 
>#35709

Re: Guix beyond 1.0: let’s have a roadmap!

[John Soo]

Hi all,

I’m a newcomer of sorts but I would like a programming abstraction over profiles. It feels like some requests for better cache file state handling, declarative user services, and declarative user packages could be gained. Plus I think profiles are still maybe the most confusing thing to a newcomer and they are not explicit in the configuration.

- John

> On Jun 27, 2019, at 11:11 PM, Julien Lepiller <julien@lepiller.eu> wrote:
> 
> Le 28 juin 2019 00:33:12 GMT+02:00, swedebugia <swedebugia@riseup.net> a écrit :
>> On 2019-06-27 21:02, Alex Griffin wrote:
>>> 
>>> ** TODO better Node.js packaging and tooling
>> 
>> This seem to have gotten stuck. But I heard something about a 
>> guile-semver and also we need to handle circular dependencies better in
>> 
>> guix to make it easier to discover and mitigate them.
>> 
>> Compared to the whole expat/JS community Guix is still a very small 
>> project. The bootstrap problems will probably take years to complete 
>> with the current pace/manpower/interest.
>> 
>> Maybe we should propose The GNU Project to create and seek funding for
>> a 
>> "fix JS (bootstrap)" campaign? Compilers will need to be written 
>> according to Julien (like rustc).
> 
> We're good with nust now :). A big issue is coffeescript and probably most of the languages that compile to javascript.
> 
>> 
>>> *** TODO package important Icecat and Ungoogled-Chromium extensions.
>> This is a pain point because IceCat steers users away from Firefox
>> Add-ons and Ungoogled-Chromium completely disallows installing from
>> Chrome Web Store.
>> 
>> Actually currently our Chrome does not support add-ons at all. See bug 
>> #35709
> 
> 

Re: Guix beyond 1.0: let’s have a roadmap!

[znavko]

** TODO make a wiki online for newcomers
** TODO make some other methods for chatting (for those who use free vpn, tor)

Re: Guix beyond 1.0: let’s have a roadmap!

[swedebugia]

On 2019-06-28 18:54, znavko@disroot.org wrote:
> ** TODO make a wiki online for newcomers
> ** TODO make some other methods for chatting (for those who use free vpn, tor)

Telegram seems to work well. Only the client is free though.

-- 
Cheers Swedebugia

Re: Guix beyond 1.0: let’s have a roadmap!

[znavko]

need to have phone for Telegram. this do not like some anonymous from linux.org.ru 

June 28, 2019 5:08 PM, "swedebugia" <swedebugia@riseup.net> wrote:

> On 2019-06-28 18:54, znavko@disroot.org wrote:
> 
>> ** TODO make a wiki online for newcomers
>> ** TODO make some other methods for chatting (for those who use free vpn, tor)
> 
> Telegram seems to work well. Only the client is free though.
> 
> -- Cheers Swedebugia

Guix beyond 1.0: let’s have a roadmap!

[Jesse Gibbons]

My wishlist (a bit wordier and less organized than what most have
responded):

- At least two have already said this, improve package searching. I
  recommend every package have an optional list of keywords or
  keyphrases to make searching a lot more reliable and possibly faster.

- Refactor the package modules. A lot of packages stand alone in their
  own module when they could fit well into an already established
  module without making it much larger.

- Document all functions or syntax exported in any guix modules (like
  substitute*) either in the guix manual or in a separate guix reference
  manual.

- Debugging/diagnostic mechanism for hanging build processes. (I want
  to know why guile-emacs takes forever to build on my machine).

- `guix import git` to more easily define packages from a git
  repository.

- A way to generate a manifest from the command line.

- A way to generate a service definition from the command line.

- A way to select services and system-wide packages in the graphical
  installer (like how aptitude lets you browse and select packages when
  installing debian)

- A way to install a service (built for mcron or shepherd) specifically
  for a user.

- #:glib-or-gtk option for (potentially) all build systems (like what
  meson-build-system currently provides). If not for all build systems,
  at least for python-build-system.

Re: Guix beyond 1.0: let’s have a roadmap!

[ison]

On Thu, Jun 27, 2019 at 06:05:27PM +0200, Ludovic Courtès wrote:
> What do *you* want Guix to address in the future?

How about a --with-version flag for guix build and guix package?
Sort of like the convenience features --with-source and --with-input for re-writing package fields but this would be convenient for rewriting the package version string.

Re: Guix beyond 1.0: let’s have a roadmap!

[pelzflorian (Florian Pelz)]

On Fri, Jun 28, 2019 at 07:35:22PM -0600, ison wrote:
> On Thu, Jun 27, 2019 at 06:05:27PM +0200, Ludovic Courtès wrote:
> > What do *you* want Guix to address in the future?
> 
> How about a --with-version flag for guix build and guix package?
> Sort of like the convenience features --with-source and --with-input for re-writing package fields but this would be convenient for rewriting the package version string.
> 

+1

This is <https://issues.guix.info/issue/35744>.

Regards,
Florian

Re: Guix beyond 1.0: let’s have a roadmap!

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

Hello,

Ludovic Courtès <ludo@gnu.org> writes:

[...]

> What do *you* want Guix to address in the future?
>
> #+TITLE: GNU Guix Beyond 1.0—A Road Map

[...]

> * infrastructure
>
> ** TODO web site officially available at https://guix.gnu.org
> ** TODO web site includes a package and service browser
> ** TODO Guix Data Service deployed
> ** TODO code and services shared between Guix Data Service and Cuirass
> ** TODO package sources are always archived on Software Heritage
> ** TODO web site translated in other languages
> ** TODO official channel registry service available

** TODO guix wheather 100%?

Could this be achieved?
Is it "just" a question of build power or do we need to address
design/organizational or coding issues?

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Guix beyond 1.0: let’s have a roadmap!

[Christopher Lemmer Webber]

Ludovic Courtès writes:

> * UI/UX
>
> ** TODO grafts and profile hooks run as “build continuations” <https://bugs.gnu.org/28310>
> ** TODO ‘package-derivation’ made faster
> ** TODO (gnu installer) UI can be used to edit config.scm
> ** TODO ‘guix system status’ shows info about the current status

I'd like to add "a GTK based GUI for managing packages and system
upgrades".  Something like Synaptic in Debian.  I think this could help
increase our userbase quite a bit.

Re: Guix beyond 1.0: let’s have a roadmap!

[Robert Vollmert]

(this should really be a top-level reply, but I missed the original mail)

On 30. Jun 2019, at 15:13, Giovanni Biscuolo <g@xelera.eu> wrote:
> 
> Hello,
> 
> Ludovic Courtès <ludo@gnu.org> writes:
> 
> [...]
> 
>> What do *you* want Guix to address in the future?
>> 
>> #+TITLE: GNU Guix Beyond 1.0—A Road Map

A bit of an outside opinion, here. I’d love to see a concerted effort making
the ecosystem a bit more friendly to work with, along the lines of

- better stack traces when things go wrong (this would be both guile work
  and guix guile-module work as far as I can tell)
- more consistent and useful output — currently it’s very easy to miss the
  actual cause of an error between a lot of noise, e.g. all those “recompiling
  scheme module” messages

Re: Guix beyond 1.0: let’s have a roadmap!

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]

Hello Alex,

"Alex Griffin" <a@ajgrf.com> writes:

[...]

> ** TODO run-time configuration system for services, similar to OpenWrt's UCI

I don't understand this: do you propose to have a CLI to add system
configuration sections to a system configuration file?

Guix EDSL is much much more flexible than UCI, AFAIU it's not so easy to
have a **generic** UI to configure a Guix System (and [re]configuring
via config.scm is simply awesome)

Thinking about all this, you remembered me my preferred item in the Guix
roadmap (maybe for Guix 3 :-) )

* UI

** TODO: (local) web application to [re]configure a Guix System, possibly starting
   from an existing config file or user selectable templates

To be clear: webUI should be *automatically* generated reading Guix
packages *and* Guix services to allow users to compose an
operating-system definition setting their preferred configuration
parameters (possibly with validation, but that should be **back
integrated** in Guix proper and _not_ hardcoded in the webUI)

With guix-deploy and `guix system reconfigure --host=…` this will allow
more users to orchestrate their infrastructure (with monitoring and
dashboard if programmed/integrated)


Happy Guix! Gio'

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Guix beyond 1.0: let’s have a roadmap!

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

Hi Guix!

Ludovic Courtès <ludo@gnu.org> writes:

[...]

> * devops
>
> ** TODO ‘guix system reconfigure --target=host.example.org’ is a thing
> ** TODO ‘guix deploy’ is a thing

** TODO a Guix version of [[NixOps][https://nixos.org/nixops/]]
   
Having the two above this last one should not be too hard to achieve
(maybe starting with less provisioning resource than the one currently
supported by NixOps)

Thoughts? Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

Hi John,

John Soo <jsoo1@asu.edu> skribis:

> I’m a newcomer of sorts but I would like a programming abstraction
> over profiles. It feels like some requests for better cache file state
> handling, declarative user services, and declarative user packages
> could be gained.

Noted.

> Plus I think profiles are still maybe the most confusing thing to a
> newcomer and they are not explicit in the configuration.

In what way do you think profiles are confusing to a newcomer?  Looking
at this with a fresh eye would be helpful!

Thanks,
Ludo’.

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

Hello!

Giovanni Biscuolo <g@xelera.eu> skribis:

> * UI
>
> ** TODO: (local) web application to [re]configure a Guix System, possibly starting
>    from an existing config file or user selectable templates
>
> To be clear: webUI should be *automatically* generated reading Guix
> packages *and* Guix services to allow users to compose an
> operating-system definition setting their preferred configuration
> parameters (possibly with validation, but that should be **back
> integrated** in Guix proper and _not_ hardcoded in the webUI)

That makes sense to me!  I think things like <https://yunohost.org/>
should benefit from declarative OS config as well as the ability to roll
back.

Thanks,
Ludo’.

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

Hi David,

"Thompson, David" <dthompson2@worcester.edu> skribis:

> * Extend 'guix environment' to cover use-cases that people currently
> use docker-compose for

Could you clarify a bit what that would mean?

> * Improve UX of 'guix environment' by using sane defaults and
> conventions such as reading from 'guix.scm' file in current directory

Yup!  I haven’t forgotten about your proposal at:

  https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00300.html

> * Add a small-scale, general-purpose, "serverless" computing
> environment a la AWS Lambda using g-expressions + call-with-container
> + a web server

Is it something akin to ‘remote-eval’ and ‘container-eval’?

  https://issues.guix.gnu.org/issue/36162

> * Improve portable application bundles so that only files needed at
> runtime (no headers, docs, etc.) are included somehow (not sure how to
> do this one)

I guess it boils down to making packages “smaller”, possibly using
multiple outputs and generally paying attention to what ‘guix size’
reports.

> * Allow system services to run unprivileged (perhaps via user
> namespaces) so that each user may have their own shepherd instance
> (would be useful for other features, too, such as the first item in
> this list)

Makes sense to me.

Thanks,
Ludo’.

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

Hello Guix!

I’ve committed the file so people can amend it:

  https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/ROADMAP.org

Please keep it rather high-level and forward-looking!  For “simpler” and
more immediate tasks, there’s always bug-guix@gnu.org, which makes it
easier to track progress.

Ludo’.

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

Julien Lepiller <julien@lepiller.eu> skribis:

> * accessible installer and installed system

+1

> * use the intensional model described in Eelco's thesis (should reduce our computing needs)

I think we should discuss what we expect from that model.

For example, “content-addressability” might not be a goal in itself: we
already have the content hash of all the store items, we already have
deduplication, and with IPFS we’d get the benefits of
content-addressability for data transfers—all without moving to the
intensional model.

Reducing computing needs might be the most compelling argument to me: in
some cases changing an input deep down in the graph wouldn’t entail any
rebuilds.  We could change (guix build utils) without triggering any
rebuild, for instance.  It wouldn’t help in other cases such as security
updates, though.

There are also practical issues: what to do with non-deterministic build
processes, how to migrate, etc.

> * channel browser (along with package and services)

Good idea!

Ludo’.

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> skribis:

> On Fri, Jun 28, 2019 at 07:35:22PM -0600, ison wrote:
>> On Thu, Jun 27, 2019 at 06:05:27PM +0200, Ludovic Courtès wrote:
>> > What do *you* want Guix to address in the future?
>> 
>> How about a --with-version flag for guix build and guix package?
>> Sort of like the convenience features --with-source and --with-input for re-writing package fields but this would be convenient for rewriting the package version string.
>> 
>
> +1
>
> This is <https://issues.guix.info/issue/35744>.

This is the kind of task that can be readily addressed (it’s not a deep
change or a completely new feature), so the bug tracker is indeed more
appropriate!

Thanks,
Ludo’.

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

Hello,

Robert Vollmert <rob@vllmrt.net> skribis:

> - better stack traces when things go wrong (this would be both guile work
>   and guix guile-module work as far as I can tell)

I agree that we must keep improving error reporting in general.  Stack
traces are very much on the Guile side of things.

OTOH, due to EDSLs in Guix, there are things where Guile itself will
display what it sees, but what it sees is not quite what you’d like to
see as a Guix hacker.  So here we can probably do better on our side.

I’d encourage you to post specific examples to bug-guix@gnu.org showing
what you get and what you’d like to see.  It’ll be easier to work from
examples that in the abstract.

> - more consistent and useful output — currently it’s very easy to miss the
>   actual cause of an error between a lot of noise, e.g. all those “recompiling
>   scheme module” messages

When do you see “recompiling” messages?

It looks like a bug we could address soonish, not a long-term task.  :-)

Thanks,
Ludo’.

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

Christopher Lemmer Webber <cwebber@dustycloud.org> skribis:

> Ludovic Courtès writes:
>
>> * UI/UX
>>
>> ** TODO grafts and profile hooks run as “build continuations” <https://bugs.gnu.org/28310>
>> ** TODO ‘package-derivation’ made faster
>> ** TODO (gnu installer) UI can be used to edit config.scm
>> ** TODO ‘guix system status’ shows info about the current status
>
> I'd like to add "a GTK based GUI for managing packages and system
> upgrades".  Something like Synaptic in Debian.  I think this could help
> increase our userbase quite a bit.

I fully agree; I had a “GNOME Software backend” item somewhere
(apparently PackageKit is moribund.)

Ludo’.

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

Hi,

Giovanni Biscuolo <g@xelera.eu> skribis:

> ** TODO a Guix version of [[NixOps][https://nixos.org/nixops/]]

That’s the ‘guix deploy’ item under “devops”.  :-)

You’ve probably seen that Jakob is working on it as part of GSoC, and
apparently making good progress!

Ludo’.

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

Hi Alex,

I think some of the items you suggests are tasks that people could start
working on right away, as opposed to long-term deep changes, so I’d
encourage you to submit them as wishlist items to bug-guix@gnu.org.

"Alex Griffin" <a@ajgrf.com> skribis:

> ** TODO use guile-bash to automatically update environment variables when the current profile changes

People don’t necessarily use Bash though, but I agree that’s something
like that would be nice, even if that’s just for a specific shell.
That’s something we can already start experimenting with!

> ** TODO run-time configuration system for services, similar to OpenWrt's UCI

What does it mean?  (I don’t know UCI.)

> * Command Line Interface
>
> ** TODO refresh able to take a contributor name and find out-of-date packages that they have contributed to
>
> ** TODO improved search: support AND terms instead of OR, configurable recfmt template

“And” is now the default.  A configurable rec template would be nice,
but it could also be hard to use and thus not very much used; anyway,
we’d need to discuss this in more detail so see what the goal is and how
we can achieve it.

> ** TODO package --show should allow multiple arguments and not require an equal sign

Maybe a ‘guix show’ alias, then?

> * Other
>
> ** TODO evaluate shepherd service definitions placed somewhere in ~/.guix-profile before evaluating ~/.config/shepherd/init.scm

+1

> ** TODO support automatic GPG/signify signature verification of origin objects

For users or for packagers?

Thanks,
Ludo’.xs

Re: Guix beyond 1.0: let’s have a roadmap!

[zimoun]

Hi,

On Fri, 28 Jun 2019 at 23:14, Jesse Gibbons <jgibbons2357@gmail.com> wrote:

> - A way to generate a manifest from the command line.

Do you mean add:
 - either an option to `guix package` as `--format=FORMAT` with FORMAT
is json, recutils etc. (see `guix describe --format`)
 - either the `guix describe` format to extend it to output packages too
?

Cheers,
simon

Re: Guix beyond 1.0: let’s have a roadmap!

[Hartmut Goebel]

Am 01.07.19 um 11:36 schrieb Ludovic Courtès:
>> * Improve portable application bundles so that only files needed at
>> runtime (no headers, docs, etc.) are included somehow (not sure how to
>> do this one)
> I guess it boils down to making packages “smaller”, possibly using
> multiple outputs and generally paying attention to what ‘guix size’
> reports.

I was thinking about this, too. E.g. automatically moving header-files
and static libs into some ":dev" output.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Guix beyond 1.0: let’s have a roadmap!

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

> Christopher Lemmer Webber <cwebber@dustycloud.org> skribis:
>
>> Ludovic Courtès writes:
>>
>>> * UI/UX
>>>
>>> ** TODO grafts and profile hooks run as “build continuations” <https://bugs.gnu.org/28310>
>>> ** TODO ‘package-derivation’ made faster
>>> ** TODO (gnu installer) UI can be used to edit config.scm
>>> ** TODO ‘guix system status’ shows info about the current status

Maybe it's a detail, but I'd like to emphasize on the UX: I find
Synaptics very poor (in fact it's not much faster to use than the
command line.

I think it's important to have live fuzzy search, range selection,
queued tasks, etc.

One of the best GUI experience I had with a package manager was that of
Antergos: I think it was called pacman-xg4.

We can also re-use the good ideas from emacs-guix.el and helm-system-packages.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Guix beyond 1.0: let’s have a roadmap!

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

>> Plus I think profiles are still maybe the most confusing thing to a
>> newcomer and they are not explicit in the configuration.
>
> In what way do you think profiles are confusing to a newcomer?  Looking
> at this with a fresh eye would be helpful!

I agree with this, I would welcome moving the profile chapter to the
foreground.  I expect it to be something new to the majority of the
users.

Like many other "modern" concepts in Guix, we need to teach them
explicitly, since implicit teaching can discourage many users.

For instance, we can explain how to use a manifest to maintain the
default profile, how to use "guix install -p PROFILE..." to maintain a
separate profile, how to effectively use them by either call
~/my-profile/bin/my-program or by sourcing etc/profile, etc.

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Guix beyond 1.0: let’s have a roadmap!

[Alex Griffin]

On Mon, Jul 1, 2019, at 10:06 AM, Ludovic Courtès wrote:
> > ** TODO run-time configuration system for services, similar to OpenWrt's UCI
> 
> What does it mean?  (I don’t know UCI.)

UCI is a configuration language and tool layered on top of the underlying packages. It gives a single machine-readable configuration format to everything, and then uses it to generate the real config files used by services. It's the thing that lets you change your router settings from the OpenWrt web interface or command line.

It's a lot like Guix system declarations, except service configuration happens at runtime. I guess the thing I really want though is a web interface.

> > ** TODO support automatic GPG/signify signature verification of origin objects
> 
> For users or for packagers?

For packagers. If a package ships with a cryptographic signature, we could commit it with the package and have Guix double check our source integrity. This would be especially helpful with `guix refresh`, because I suspect not everybody is as diligent about integrity checking when Guix just generates a working hash for you.

-- 
Alex Griffin

Re: Guix beyond 1.0: let’s have a roadmap!

[Jesse Gibbons]

On Mon, 1 Jul 2019 12:14:23 +0200
zimoun <zimon.toutoune@gmail.com> wrote:

> Hi,
> 
> On Fri, 28 Jun 2019 at 23:14, Jesse Gibbons <jgibbons2357@gmail.com>
> wrote:
> 
> > - A way to generate a manifest from the command line.  
> 
> Do you mean add:
>  - either an option to `guix package` as `--format=FORMAT` with FORMAT
> is json, recutils etc. (see `guix describe --format`)
>  - either the `guix describe` format to extend it to output packages
> too ?
> 
> Cheers,
> simon

I meant a command that accepts the names of packages and outputs a
manifest file that could be used with any of the commands that accepts
the "--manifest=" option. When I wrote that, I thought the only way to
easily make a manifest file with the packages I want was to generate
it. I have since read the docuentation again and now understand that is
not the case.

Re: Guix beyond 1.0: let’s have a roadmap!

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

Hello!

Ludovic Courtès <ludo@gnu.org> writes:

> Giovanni Biscuolo <g@xelera.eu> skribis:
>
>> * UI
>>
>> ** TODO: (local) web application to [re]configure a Guix System, possibly starting
>>    from an existing config file or user selectable templates

[...]

> That makes sense to me!  I think things like <https://yunohost.org/>
> should benefit from declarative OS config as well as the ability to roll
> back.

Thanky you for supporting this goal :-)

Another project we should take/give inspiration from/to is maybe Rudder
https://www.rudder.io/en/

«multi-platform Continuous Configuration solution (combination of
configuration management and continuous audit) dedicated to production
infrastructure needs»

With `guix deploy` and GWL in development, cuirass and monitoring
services/agents we should be able to use Guix+GWL to design, implement,
manage and monitor entire infrastrutctures - workflow management -
included, hopefully with a (local) webUI :-)

Thanks! Gio'.

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Guix UCI comparison (was Re: Guix beyond 1.0: let’s have a roadmap!)

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 2809 bytes --]

Hello Alex,

I know and use UCI (and sometimes LuCI, the web interface) so I'm adding
(added) my two cents to clarify the respective ecosystems

I may repeat concepts/info some af you may already well know, please
forgive me :-)

"Alex Griffin" <a@ajgrf.com> writes:

>> What does it mean?  (I don’t know UCI.)
>
> UCI is a configuration language and tool layered on top of the
> underlying packages.

UCI [1] short description: «small utility written in C (a shell
script-wrapper is available as well) and is intended to centralize the
whole configuration of a device running OpenWrt.»

How UCI works [2]:
«Applications are made UCI-compatible by simply writing the original
configuration file (which is read by the program) according to the
chosen settings in the corresponding UCI file. This is done upon running
the initialization scripts in /etc/init.d/. See Init scripts for more
information. Thus, when starting a daemon with such a UCI-compatible
initialization script, you should be aware that the program's original
configuration file gets overwritten.»

In Guix we have a full EDSL for service configuration (UCI lacks package
management) and activation; it's Guile based and it's much more powerful
than the custom augeas-like [3] UCI configuration API.

> It gives a single machine-readable configuration format to everything,

To every service for which a custom init file has been written; almost
averything in OpenWRT has a custom init file but not all [4]

In Guix we should go on defining more and more service, some still
really missing (Samba for example, AFAIU)

> and then uses it to generate the real config files used by
> services. It's the thing that lets you change your router settings
> from the OpenWrt web interface or command line.

UCI is for command line, LuCI is UCI web interface written in LUA that
uses UCI for configuration/reconfiguration of services.

> It's a lot like Guix system declarations, except service configuration
> happens at runtime.

Guix service reconfiguration happens at `guix system reconfgigure` time ;-)

It's interesting UCI, like Guix, does not automatically (AFAIU) restarts
services upon reconfiguration :-D

> I guess the thing I really want though is a web interface.

You name it! :-D

HTH. Gio'.



[1] https://openwrt.org/docs/techref/uci

[2] https://openwrt.org/docs/guide-user/base-system/uci

[3] http://augeas.net/

[4] https://openwrt.org/docs/guide-user/base-system/notuci.config


P.S.: I'd really like one day to be able to replace OpenWRT+UCI with a
Guix generated (read-only?) system image deployed on my perimetral
office router the usual way, configured via a (local) web UI :-O


[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Guix beyond 1.0: let’s have a roadmap!

[Robert Vollmert]

> On 1. Jul 2019, at 11:55, Ludovic Courtès <ludo@gnu.org> wrote:
> 
> Hello,
> 
> Robert Vollmert <rob@vllmrt.net> skribis:
> 
>> - better stack traces when things go wrong (this would be both guile work
>>  and guix guile-module work as far as I can tell)
> 
> I agree that we must keep improving error reporting in general.  Stack
> traces are very much on the Guile side of things.
> 
> OTOH, due to EDSLs in Guix, there are things where Guile itself will
> display what it sees, but what it sees is not quite what you’d like to
> see as a Guix hacker.  So here we can probably do better on our side.
> 
> I’d encourage you to post specific examples to bug-guix@gnu.org showing
> what you get and what you’d like to see.  It’ll be easier to work from
> examples that in the abstract.
> 
>> - more consistent and useful output — currently it’s very easy to miss the
>>  actual cause of an error between a lot of noise, e.g. all those “recompiling
>>  scheme module” messages
> 
> When do you see “recompiling” messages?

Here’s an example:  ~/guix-postgrest$ guix build -L . postgrest
;;; note: source file ./bytestring.scm
;;;       newer than compiled /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/bytestring.go
;;; note: source file ./check.scm
;;;       newer than compiled /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/check.go
;;; note: source file ./control.scm
;;;       newer than compiled /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/control.go
;;; note: source file ./text.scm
;;;       newer than compiled /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/text.go
;;; note: source file ./data.scm
;;;       newer than compiled /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/data.go
;;; note: source file ./more-data.scm
;;;       newer than compiled /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/more-data.go
;;; note: source file ./containers.scm
;;;       newer than compiled /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/containers.go
;;; note: source file ./core.scm
;;;       newer than compiled /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/core.go
;;; note: source file ./postgrest-deps.scm
;;;       newer than compiled /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/postgrest-deps.go
;;; note: source file ./postgrest.scm
;;;       newer than compiled /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/postgrest.go
;;; note: source file ./sql.scm
;;;       newer than compiled /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/sql.go
;;; note: source file ./template.scm
;;;       newer than compiled /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/template.go
;;; note: source file ./wai.scm
;;;       newer than compiled /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/wai.go
;;; note: source file ./service.scm
;;;       newer than compiled /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/service.go
;;; note: source file ./service.scm
;;;       newer than compiled /home/rob/.cache/guile/ccache/2.2-LE-8-3.A/home/rob/guix-postgrest/service.scm.go
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
[…]

I’m working in a directory that’s a local checkout of my “postgrest” guix channel.

> It looks like a bug we could address soonish, not a long-term task.  :-)

I’m certainly in favour of fixing these things as they show up, and will continue
to report them.

My reason for the suggestion is that my general impression is that error messages
and useful console output is not a priority that’s generally agreed upon. And
making that a stated goal might help to change that. :)

Robert

Re: Guix beyond 1.0: let’s have a roadmap!

[matias_jose_seco]

I dream to reach a (digital) place, where a Guix Logo brights in the 
center of the door (intro web page), and scattered all around it, 
signposts (Links) of all imaginable languages, broadcast "Welcome" 
(Bienvenido, Nnabata, أهلا بك, 歡迎, добро пожаловать, ...).


Singular is, many digital adventurers are exploring places which uses 
their own language [1].
This wish is interestingly expressed by the Localization Lab [2],
which introduces technological terms within unrepresented languages, for 
Projects which, i feel, follows the GNU spirit [3].


1: 
https://www.localizationlab.org/blog/2019/3/7/hl8xdh6nacw5bpe5v4skhjkv0smeda
2: https://www.localizationlab.org/about-us
3: https://www.localizationlab.org/projects-1

PS: I was wondering, which is the actual feeling to traverse the Gnunet 
and Fediverse cosmos ?

Have a nice journey, Matias :)

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

Hi,

"Alex Griffin" <a@ajgrf.com> skribis:

> On Mon, Jul 1, 2019, at 10:06 AM, Ludovic Courtès wrote:
>> > ** TODO run-time configuration system for services, similar to OpenWrt's UCI
>> 
>> What does it mean?  (I don’t know UCI.)
>
> UCI is a configuration language and tool layered on top of the underlying packages. It gives a single machine-readable configuration format to everything, and then uses it to generate the real config files used by services. It's the thing that lets you change your router settings from the OpenWrt web interface or command line.
>
> It's a lot like Guix system declarations, except service configuration happens at runtime. I guess the thing I really want though is a web interface.

Giovanni Biscuolo <g@xelera.eu> skribis:

> UCI [1] short description: «small utility written in C (a shell
> script-wrapper is available as well) and is intended to centralize the
> whole configuration of a device running OpenWrt.»
>
> How UCI works [2]:
> «Applications are made UCI-compatible by simply writing the original
> configuration file (which is read by the program) according to the
> chosen settings in the corresponding UCI file. This is done upon running
> the initialization scripts in /etc/init.d/. See Init scripts for more
> information. Thus, when starting a daemon with such a UCI-compatible
> initialization script, you should be aware that the program's original
> configuration file gets overwritten.»

Interesting!  Perhaps there are lessons to be learned from OpenWRT’s
experience building UCI and its web interface?  And also from Augeas.

>> > ** TODO support automatic GPG/signify signature verification of origin objects
>> 
>> For users or for packagers?
>
> For packagers. If a package ships with a cryptographic signature, we could commit it with the package and have Guix double check our source integrity. This would be especially helpful with `guix refresh`, because I suspect not everybody is as diligent about integrity checking when Guix just generates a working hash for you.

Note: s/integrity/authenticity/

‘guix refresh’ automatically checks OpenPGP signatures when they exist.

However, that authenticity check is necessarily out-of-band: there’s
nothing we can commit in Guix proper regarding that check.  The good
thing is that we have complete history of all the changes made to Guix,
so anyone can at any time authenticate the source code that Guix refers
to.

Perhaps what we could do is provide users with a tool to authenticate
the source code of specific packages, pretty much like ‘guix refresh’
does.

What’s more important, though, is authenticating checkouts of Guix
itself since it’s at the root of everything:
<https://issues.guix.gnu.org/issue/22883>.

Thanks,
Ludo’.

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>>> Plus I think profiles are still maybe the most confusing thing to a
>>> newcomer and they are not explicit in the configuration.
>>
>> In what way do you think profiles are confusing to a newcomer?  Looking
>> at this with a fresh eye would be helpful!
>
> I agree with this, I would welcome moving the profile chapter to the
> foreground.  I expect it to be something new to the majority of the
> users.
>
> Like many other "modern" concepts in Guix, we need to teach them
> explicitly, since implicit teaching can discourage many users.
>
> For instance, we can explain how to use a manifest to maintain the
> default profile, how to use "guix install -p PROFILE..." to maintain a
> separate profile, how to effectively use them by either call
> ~/my-profile/bin/my-program or by sourcing etc/profile, etc.

That makes sense to me.  Perhaps we could have a “Managing Profiles”
section right before or after “Invoking guix package”, and/or move
introductory material from “Invoking guix package” into a new “Package
Management Overview” section right before “Invoking guix package”, and
explicitly introduce the notion of a profile and give examples like
those you mention.

That’d be a welcome improvement!

Ludo’.

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

Hi,

matias_jose_seco@autoproduzioni.net skribis:

> I dream to reach a (digital) place, where a Guix Logo brights in the
> center of the door (intro web page), and scattered all around it,
> signposts (Links) of all imaginable languages, broadcast "Welcome"
> (Bienvenido, Nnabata, أهلا بك, 歡迎, добро пожаловать, ...).
>
>
> Singular is, many digital adventurers are exploring places which uses
> their own language [1].
> This wish is interestingly expressed by the Localization Lab [2],
> which introduces technological terms within unrepresented languages,
> for Projects which, i feel, follows the GNU spirit [3].

Thanks for bringing this up.  I’m very much convinced this is an
important task, and I’m happy there’s already a team of dedicated
volunteers who’ve worked hard translating the manual and messages!

The next obvious step is to translate the web site.  There were open
questions as to how to do it, but I think Julien and Florian had more or
less found a way forward, so I hope we can work on it soonish.

Thanks,
Ludo’.

Re: Guix beyond 1.0: let’s have a roadmap!

[Ricardo Wurmus]

Hi Robert,

>>> - more consistent and useful output — currently it’s very easy to miss the
>>>  actual cause of an error between a lot of noise, e.g. all those “recompiling
>>>  scheme module” messages
>>
>> When do you see “recompiling” messages?
>
> Here’s an example:  ~/guix-postgrest$ guix build -L . postgrest
> ;;; note: source file ./bytestring.scm
> ;;;       newer than compiled /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/bytestring.go
> ;;; note: source file ./check.scm
> ;;;       newer than compiled /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/check.go

This is certainly not normal.  Why do you use “-L .” here?  I don’t
think we recommend this anywhere in the manual.  It does not look like a
common use case.

When we develop packages we do this from a git checkout where we compile
modules with “make” to get rid of these messages.

Having the messages is good, though, because interpreting these files
instead of using the compiled variants comes with a massive drop in
performance.  Since users who don’t develop their own modules won’t ever
see these message I think it is a reasonable reminder to developers to
compile their modules.

> My reason for the suggestion is that my general impression is that error messages
> and useful console output is not a priority that’s generally agreed upon.

It certainly is a priority as demonstrated by the full (but
unfortunately failed) Outreachy internship project to overhaul console
output, which was later picked up by me and later massively extended by
Ludovic to hide build output by default, add spinners, colours, hints,
etc.

Any further work in that direction would be very welcome, though I’m
afraid that the low-hanging fruit has already been plucked.

--
Ricardo

Re: Guix beyond 1.0: let’s have a roadmap!

[Robert Vollmert]

> On 9. Jul 2019, at 12:22, Ricardo Wurmus <rekado@elephly.net> wrote:
> 
> 
> Hi Robert,
> 
>>>> - more consistent and useful output — currently it’s very easy to miss the
>>>> actual cause of an error between a lot of noise, e.g. all those “recompiling
>>>> scheme module” messages
>>> 
>>> When do you see “recompiling” messages?
>> 
>> Here’s an example:  ~/guix-postgrest$ guix build -L . postgrest
>> ;;; note: source file ./bytestring.scm
>> ;;;       newer than compiled /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/bytestring.go
>> ;;; note: source file ./check.scm
>> ;;;       newer than compiled /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/check.go
> 
> This is certainly not normal.  Why do you use “-L .” here?

~/guix-postgrest is a git repository that houses some in-development packages of mine.
E.g. there’s a file postgrest.scm that has the definition of the postgrest package,
and the file check.scm that has definitions of a number haskell dependencies that
are not in guix proper yet.

guix build -L . <package-name>

then seems like the straightforward way to interactively test that package definition
without going through any git push, guix pull etc.

> Having the messages is good, though, because interpreting these files
> instead of using the compiled variants comes with a massive drop in
> performance.

Why doesn’t guile silently do the right thing instead?

Cheers
Robert

Re: Guix beyond 1.0: let’s have a roadmap!

[P]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

On Thursday, June 27, 2019 6:05 PM, Ludovic Courtès <ludo@gnu.org> wrote:

> What do you want Guix to address in the future?

Another thing that is super important:

Documentation that is easier to navigate. Ideally as good or better than the Arch Wiki.

[-- Attachment #2: ROADMAP.org --]
[-- Type: text/plain, Size: 2014 bytes --]

#+TITLE: GNU Guix Beyond 1.0—A Road Map

* ‘guix pull’

** TODO 'guix pull' & commit authentication <https://bugs.gnu.org/22883>
** TODO build-self.scm trampoline runs faster

* UI/UX

** TODO grafts and profile hooks run as “build continuations” <https://bugs.gnu.org/28310>
** TODO ‘package-derivation’ made faster
** TODO (gnu installer) UI can be used to edit config.scm
** TODO ‘guix system status’ shows info about the current status

* core

** TODO substitutes can be published and fetched over IPFS <https://issues.guix.gnu.org/issue/33899>
** TODO ‘wip-build-systems-gexp’ branch updated & merged
** TODO labels removed from the inputs fields of packages
** TODO [[https://gitlab.com/rutger.van.beusekom/gash][Gash]] used instead of Bash during bootstrap
** TODO Guix System can run GNU/Hurd
** TODO shepherd uses Fibers, logs correctly, can do “socket activation”
** TODO (guix record) provides optional static type checking

* build daemon

** TODO daemon rewritten in Scheme
** TODO daemon supports “recursive derivations”
** TODO daemon supports more hash algorithms
** TODO daemon stores zero or more narinfo signatures per store item

* devops

** TODO ‘guix system reconfigure --target=host.example.org’ is a thing
** TODO ‘guix deploy’ is a thing

* miscellaneous

** TODO ‘static-networking-service’ supports IPv6
** TODO Debian package for Guix is available
** TODO ‘--with-least-authority’ package transformation + ‘guix run’ added
** TODO GNOME Software backend written
** TODO GTK+ can use Guix “powerbox” instead of Flatpak’s

* infrastructure

** TODO web site officially available at https://guix.gnu.org
** TODO web site includes a package and service browser
** TODO Guix Data Service deployed
** TODO code and services shared between Guix Data Service and Cuirass
** TODO package sources are always archived on Software Heritage
** TODO web site translated in other languages
** TODO official channel registry service available

Re: Guix beyond 1.0: let’s have a roadmap!

[Ricardo Wurmus]

P <pronaip@protonmail.com> writes:

> Documentation that is easier to navigate. Ideally as good or better
> than the Arch Wiki.

I think the Guix manual is really easy to navigate thanks to the curated
index.  We may want to include the JavaScript info reader navigation to
our build of the HTML documentation, so that the index can be used more
easily in a browser.

--
Ricardo

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> P <pronaip@protonmail.com> writes:
>
>> Documentation that is easier to navigate. Ideally as good or better
>> than the Arch Wiki.
>
> I think the Guix manual is really easy to navigate thanks to the curated
> index.  We may want to include the JavaScript info reader navigation to
> our build of the HTML documentation, so that the index can be used more
> easily in a browser.

I concur; or did you have something else in mind when you mentioned
navigation?  Was it about the structure of the manual, the indexes?

Thanks,
Ludo’.

Re: Guix beyond 1.0: let’s have a roadmap!

[Ben Sturmfels]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

Sorry, same as Robert, I've lost the original mail.

>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>> [...]
>>
>>> What do *you* want Guix to address in the future?
>>>
>>> #+TITLE: GNU Guix Beyond 1.0—A Road Map

I'd love to be able to annotate user and system generations with some
text, so that the text is shown back to me when running
"--list-generations". For example:

 - "Everything working, don't delete!" or
 - "Testing with CUPS service disabled" or
 - "Excluded Jupyter as build is currently failing" or
 - "Trialing CSVkit"

That way I can look back at `guix package --list-generations` and know
what's I ought to keep or delete. Otherwise all you have is the list of
packages but no information about the intent of each generation.

It would be helpful to be able to do this at the time of creating the
generation and also afterwards.

Regards,
Ben

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Guix beyond 1.0: let’s have a roadmap!

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 189 bytes --]

I like the idea: this would effectively turn generations into 1st class
commits!
Thinking about it, that makes perfect sense, doesn't it?

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Guix beyond 1.0: let’s have a roadmap!

[Ludovic Courtès]

Hello!

Ben Sturmfels <ben@sturm.com.au> skribis:

> I'd love to be able to annotate user and system generations with some
> text, so that the text is shown back to me when running
> "--list-generations". For example:
>
>  - "Everything working, don't delete!" or
>  - "Testing with CUPS service disabled" or
>  - "Excluded Jupyter as build is currently failing" or
>  - "Trialing CSVkit"
>
> That way I can look back at `guix package --list-generations` and know
> what's I ought to keep or delete. Otherwise all you have is the list of
> packages but no information about the intent of each generation.

I like the idea!  Manifest entries have a ‘properties’ field that gets
serialized, and we could use that to store user-provided messages
(comments at the level of the manifest itself would be a better fit, but
I think it’s OK.)

Thanks,
Ludo’.