Re: language-specific packages

[Andrew Tropin]

On 2024-03-02 23:20, Hartmut Goebel wrote:

> Hi Andrew,
>
> a few days ago you planed (but canceled) to stream about management of 
> Elixir projects with Guix and why it's better not to package 
> language-specific packages with Guix.
>
> I still have ejabberd in my pipeline which would add quite some Erlang 
> and Elixir packages to Guix. Thus I would be eager to learn your ideas 
> prior to pushing these packages to Guix. May I ask you to share your 
> thoughts?! Thanks.

Hi Hartmut!

I canceled the stream, but made a video on transitive package management
and used elixir and mix for demonstration purposes in it:
https://diode.zone/w/vCvgAWuTCruYuhCJ2ZccTh
https://yewtu.be/watch?v=s3VO9Kb0sHw

My point is that packaging libraries and other language-specific
packages (which are not needed for any mainstream software) cause more
harm than good: it increases maintanance burden, makes the repository
and channel bigger, version bump commits more frequent, operations on it
slower, the code base harder to grasp due to sizes.

If the package is needed for development it should be created from lock
file of the language's package manager (if it provides all needed
information like dependencies, checksums).

It's my personal opinion, not the one of Guix project.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: btrfs recommended layout for snapshots?

[Andrew Tropin]

On 2023-08-18 01:58, Nicolas Graves wrote:

> On 2023-08-16 10:10, Nicolas Graves wrote:
>
>> I guess it's possible to do the same with my home as well (thus only
>> saving actual data and not consecutive linking metadata), but that might
>> require some more time and fine-grained applications considerations.
>>
>> One weakness from this impermanence feature is that it's actually
>> application-dependent. For guix-system it's not very damaging (except if
>> we want very low-level optimizations, like setting nodatacow on
>> subvolumes with databases etc), but for guix-home, it makes things much
>> more difficult. @Andrew Tropin : maybe that's something we could in RDE in
>> a state-btrfs in (gnu home-services state) if we find a way to migrate
>> directories to subvolumes safely and reproducibly.
>
> Some notes about more progress I've done.
>
> My attempt to also load the /home subvolume on tmfps has quite
> progressed. I've created the following subvolumes :
>
> ;; App related (apps who doesn't entirely follow the XDG base directory
> ;; specification and save data or cache outside of XDG_DATA_HOME,
> ;; XDG_STATE_HOME and XDG_CACHE_HOME. Other users may need other app dirs.
>
> /home/graves/.config/chromium
> /home/graves/.config/emacs
> /home/graves/.config/libreoffice
> /home/graves/.config/guix
> /home/graves/.ssh
>
> ;; XDG_CACHE_HOME, XDG_STATE_HOME, XDG_DATA_HOME (I'm using RDE)
>
> /home/graves/.cache
> /home/graves/.local
>
> ;; And some personal want-to-save directories.
>
> /home/graves/archives
> /home/graves/resources
> /home/graves/projects
> /home/graves/spheres
>
> The only thing that seems to get in my way to achieve this properly
> is... .guix-home! Which I don't want to backup since it's only a link
> and that would require at least /home/graves/ to be snapshotted.
>
> I thus have a proposition for discussion :
> Make .guix-home XDG base dir compliant by storing a symlink
> in $XDG_CONFIG_DIR/guix/home to /var/guix/per-user/$user/guix-home
> instead of the current default of the symlink
> in /home/$user/.guix-home to the actual object in the store.
>
> This was discussed in a previous mail thread :
> "RFC: Configurable placing of the ~/.guix-home symlink"
> With Andrew concluding that
>
>>  Back in the day, the implementation of Guix Home required a symlink in
>>  home directory, right now due to improvements in symlink-manager and
>>  reconfigure code it's probably not necessary and with a few patches
>>  /var/guix/profiles/per-user/bob/guix-home/ can be used instead.
>
> With a first glance, I think it's possible to do in the code, since the
> home-run-on-first-login-service-type already gets the UID of the user,
> and with the following guile function :
>
> Scheme Procedure: passwd:name pw
> The name of the userid.
>
> we should be able to get the name of the user and replace
> ~/.guix-home with /var/guix/per-user/$user/guix-home everywhere.
> So the code where a hardlink is needed will be, and the "pleasing UX of
> searching within guix home" would also be possible.
>
> I also don't really see the reason why .guix-home shouldn't be
> $XDG_CONFIG_DIR/guix/home since it's really user-specific and unique
> (and XDG user dirs are too), unlike .guix-profile.

I don't have all the context loaded in my head right now, but it's
probably possible now, and we can try to implement it.  Feel free to
send a patch and Cc me or continue the discussion on "RFC: Configurable
placing of the ~/.guix-home symlink".

>
> This may be the one of the only missing step to make the (manual and
> only with directories (btrfs subvolumes), at least for now)
> implementation of impermanence (a quick reminder of the idea implemented
> by nix here : https://nixos.wiki/wiki/Impermanence) on with guix home, I
> would appreciate some feedback comments on the idea ;) (another step
> would be to actually activate the home environment on login in
> home-shell-profile-service-type, but migrating .guix-home would be a
> requirement).

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Guix system init but for guix home

[Andrew Tropin]

On 2023-08-04 20:40, pa...@disroot.org wrote:

> Christian Miller  writes:
>> Basically my idea would be, that I am on the live ISO and run guix system 
>> init
>> [...] and after that I would run guix home init home.scm /mnt or something 
>> like
>> that.  Now if I reboot in to the actual system, I have my complete setup with
>> EXWM and Emacs completely configured and ready to go.
>
> Something that would cover this use case be a HOME-ENVIRONMENT field for
> user-accounts in /etc/config.scm:
>
>   (user-account
>(name "paren")
>...
>(home-environment
> ...))
>
> which could either be a file-like that evaluates to a Scheme file that
> returns a HOME-ENVIRONMENT object, or a HOME-ENVIRONMENT by itself:
>
>   ;; with local-file
>   (home-environment
>(local-file
> (string-append (dirname (get-current-filename))
>"/home-paren.scm")))
>
>   ;; with home-environment
>   (home-environment
>(home-environment
> (services (cons* ...))
> (packages (list ...
>
>   -- (
>

Hi everyone!

The implementation for this functionality is here:

https://git.sr.ht/~abcdw/rde/tree/3b81be46d3d6891663f857172bc00b46f0e1eafa/src/gnu/services/home.scm#L1

The discussion of it is here:

https://issues.guix.gnu.org/56669

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Emacs next variants

[Andrew Tropin]

On 2023-04-26 18:52, Mekeor Melire wrote:

> 2023-03-10 16:39 zimon.touto...@gmail.com:
>
>> As far I know, this branch does not contain the feature 
>> Tree-sitter. Instead, the feature Tree-sitter is in the branch 
>> "master", which will be branched later as Emacs 30 and somehow 
>> will be the next next release of Emacs.
>
> 2023-03-12 12:47 and...@trop.in:
>
>> Sure, I think [...] after emacs-30 release we will include 
>> tree-sitter in emacs package itself and also we will be able to 
>> move emacs-next-pgtk to emacs-pgtk.
>
> Emacs 29.1 will support tree-sitter. This mail-thread seems to 
> have been mislead by the wrong assumption that Emacs 30 will be 
> the first version to support tree-sitter.
>
> Feel free to check "etc/NEWS" within branch "emacs-29" of Emacs' 
> repository and correct me if I'm wrong: 
> https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-29#n36

You are right, thank you for the note!  BTW, Liliana is working on Emacs
29 preparation right now and adjusting respective emacs packages here:

https://issues.guix.gnu.org/63984

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Free Style Nginx Service Type

[Andrew Tropin]

There was a few flaws in the current implementation of nginx guix
service type, for example the one described here:
https://issues.guix.gnu.org/37388

There are other things, for example it's really hard or even impossible
to implement some cases in a sane way: adding rtmp context and later
extending it from other guix services and probably much more.

In the report above created by Ludo, he mentioned an idea of using
s-expressions for representing nginx configuration, like sxml for xml.

I prototyped such implementation and even migrated my personal nginx
instance to it.  It works quite well and implementation of service type
became really simple:
https://git.sr.ht/~abcdw/rde/tree/e5bcfc0654/src/rde/system/services/web.scm#L43

It allows to generate configuration in much more programmatic way and
have much less boilerplate.  My real-world nginx configuration itself:
https://git.sr.ht/~abcdw/trop.in/tree/4eb2e07d38/src/tropin/machines.scm#L24

which expands to:
--8<---cut here---start->8---
user nginx nginx;
pid /var/run/nginx/pid;

load_module 
/gnu/store/19apmplkgpmnvn963cfydgjhhnvpf9fs-nginx-rtmp-module-1.2.2/etc/nginx/modules/ngx_rtmp_module.so;

events {
}

http {
  server_tokens off;
  proxy_temp_path /var/run/nginx/proxy_temp;
  include 
/gnu/store/lavf43rgvvmi9a6hqi8f2lmmavipq0vd-nginx-1.23.3/share/nginx/conf/mime.types;
  server {
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;

ssl_certificate /srv/nginx/ssl/hundredrps.pem;
ssl_certificate_key /srv/nginx/ssl/hundredrps.key;
ssl_protocols TLSv1.2;

server_name guix.trop.in guix.ygg.trop.in;

location / {
  proxy_pass https://guix.gnu.org;
  proxy_set_header HOST guix.gnu.org;
}
  }

  server {
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;

ssl_certificate /srv/nginx/ssl/hundredrps.pem;
ssl_certificate_key /srv/nginx/ssl/hundredrps.key;
ssl_protocols TLSv1.2;

server_name ci.guix.trop.in ci.guix.ygg.trop.in;

location / {
  proxy_pass https://ci.guix.gnu.org;
  proxy_set_header HOST ci.guix.gnu.org;
}
  }

  server {
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;

ssl_certificate /srv/nginx/ssl/hundredrps.pem;
ssl_certificate_key /srv/nginx/ssl/hundredrps.key;
ssl_protocols TLSv1.2;

server_name issues.guix.trop.in issues.guix.ygg.trop.in;

location / {
  proxy_pass https://issues.guix.gnu.org;
  proxy_set_header HOST issues.guix.gnu.org;
}
  }

  server {
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;

ssl_certificate /etc/letsencrypt/live/trop.in/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/trop.in/privkey.pem;
ssl_protocols TLSv1.2;

server_name trop.in *.trop.in;

location /rde/meetups {
  return 302 https://meet.jit.si/rde-meetup;
}
location / {
  root /srv/nginx/trop.in;
  if ($request_uri ~ ^/(.*)\.html(\?|$)) {
return 302 /$1;
  }
  try_files $uri $uri.html $uri/ =404;
}
  }

  server {
listen 80;
listen [::]:80;

server_name files.trop.in files.ygg.trop.in;
root /srv/nginx/public;
autoindex on;
  }
}

rtmp {
  server {
listen 1935;
chunk_size 4096;
application live {
  live on;
  push rtmp://a.rtmp.youtube.com/live2/key1;
  push rtmp://diode.zone:1935/live/key2;
  record off;
}
  }
}
--8<---cut here---end--->8---



The configuration structure and merge logic is visible in tests:
https://git.sr.ht/~abcdw/rde/tree/e5bcfc0654/tests/rde/serializers/nginx-test.scm#L159
https://git.sr.ht/~abcdw/rde/tree/e5bcfc0654/src/rde/serializers/nginx.scm#L20

The merge logic have a few problems rn, which I highlighted in those
xtests: https://git.sr.ht/~abcdw/rde/commit/e5bcfc0654


LMKWYT!

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

ci.guix.gnu.org proxy blocked

[Andrew Tropin]

Hello guix!

ci.guix.gnu.org is not available in some countries and I maintain a
nginx proxy for it at ci.guix.trop.in.

From time to time the proxy host get rate limited with following message
from ci.guix.gnu.org:

--8<---cut here---start->8---
Blocked because of DoS Attack
Your computer has been blocked because a DoS attack
originating from your system was detected. For more
information, contact the system administrator.
--8<---cut here---end--->8---

and becomes very slow.

Can we workaround it somehow?


Also, we provide ci.guix.ygg.trop.in, which make it available over
yggdrasil network (which is censorship-resistant and quite fast and also
packaged/serviced in guix).  https://yggdrasil-network.github.io/

Maybe we can setup yggdrasil node on ci.guix.gnu.org, to make it
possible to access it directly and not via proxy?  We have a tor node on
ci.guix.gnu.org, but it's very slow comparing to yggdrasil.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Emacs next variants

[Andrew Tropin]

On 2023-03-12 08:46, Liliana Marie Prikler wrote:

> Am Sonntag, dem 12.03.2023 um 09:18 +0400 schrieb Andrew Tropin:
>> > As for tree-sitter-with/without-gtk, I have no opinion here.  We
>> > could try exporting package rewriters so that everyone can have
>> > their cup of tea, but maintaining one's own Emacs on the
>> > user/channel level ought not to be too difficult either.
>> 
>> I guess inheriting pgtk from tree-sitter looks most logical here: no
>> potential problems for X users, tree-sitter for wayland users. 
>> Updated the inheritance hierarchy.
> For the future, I think we should be careful not to be too close to the
> master branch.  emacs-next has thus far historically been a package to
> try out things for the next release, not the one after that.  The
> inclusion of a package variant with tree-sitter necessitated a change,
> but for packages that don't need it we should go back to tailing pre-
> releases as soon as reasonable.

Sure, I think after the release of emacs-29 we can make emacs-next to
track emacs-30 and deprecate emacs-next-tree-sitter and after emacs-30
release we will include tree-sitter in emacs package itself and also we
will be able to move emacs-next-pgtk to emacs-pgtk.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Emacs next variants

[Andrew Tropin]

On 2023-03-10 20:36, Liliana Marie Prikler wrote:

> Am Freitag, dem 10.03.2023 um 22:44 +0400 schrieb Andrew Tropin:
>> > > Thanks for pointing that.  From my understanding, it does not
>> > > change what Cayetanos is raising: emacs-next-tree-sitter is built
>> > > using '--with-pgtk'.  In fact, the package emacs-next-tree-sitter
>> > > is built using the master branch (Emacs 30 unbranched yet) with
>> > > tree-sitter *and* pgtk support.
>> > > 
>> > > Cheers,
>> > > simon
>> > 
>> > As for the NEWS-29 file:
>> > 
>> > "Running this configuration on X is known to have problems, such as
>> > undesirable frame positioning and various issues with keyboard
>> > input of sequences such as 'C-;' and 'C-S-u'."
>> > 
>> > C.
>> 
>> I haven't used X for a while, but if it's still the case for 30
>> version, I guess we can inherit pgtk from tree-sitter.
> Correct me if I'm wrong, but isn't the point of C-S-u with pure GTK to
> use GNOME's ibus widget?  Granted, we have other problems with ibus
> currently, but it's still a part that makes the pgtk branch feel
> gnomier.
>

I'm not very into the details of implementation of pgtk and how it
affects C-S-u, also, I don't usually use C-S-u, so can't say much here.

> As for tree-sitter-with/without-gtk, I have no opinion here.  We could
> try exporting package rewriters so that everyone can have their cup of
> tea, but maintaining one's own Emacs on the user/channel level ought
> not to be too difficult either.

I guess inheriting pgtk from tree-sitter looks most logical here: no
potential problems for X users, tree-sitter for wayland users.  Updated
the inheritance hierarchy.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Emacs next variants

[Andrew Tropin]

On 2023-03-10 21:39, Cayetano Santos wrote:

>>ven. 10 mars 2023 at 22:44, Andrew Tropin  wrote:
>
>> [[PGP Signed Part:Undecided]]
>> On 2023-03-10 19:24, Cayetano Santos wrote:
>>
>>>>ven. 10 mars 2023 at 19:14, Simon Tournier  wrote:
>>>
>>>> Hi,
>>>>
>>>> On Fri, 10 Mar 2023 at 17:59, John Kehayias
>>>>  wrote:
>>>>
>>>>> During this discussion some changes were made to this inheritance 
>>>>> structure in
>>>>>
>>>>> <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=b4c64ddce44bb31332784c3f8e037bd565194604>
>>>>>
>>>>> and
>>>>>
>>>>> <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=070c335a91d5c245f0360e12c794e9109f9faaf1>
>>>>
>>>> Thanks for pointing that.  From my understanding, it does not change
>>>> what Cayetanos is raising: emacs-next-tree-sitter is built using
>>>> '--with-pgtk'.  In fact, the package emacs-next-tree-sitter is built
>>>> using the master branch (Emacs 30 unbranched yet) with tree-sitter
>>>> *and* pgtk support.
>>>>
>>>> Cheers,
>>>> simon
>>>
>>> As for the NEWS-29 file:
>>>
>>> "Running this configuration on X is known to have problems, such as
>>> undesirable frame positioning and various issues with keyboard input of
>>> sequences such as 'C-;' and 'C-S-u'."
>>>
>>> C.
>>
>> I haven't used X for a while, but if it's still the case for 30 version,
>> I guess we can inherit pgtk from tree-sitter.
>>
>> This will update emacs-next-pgtk from emacs-29 to somewhere near 30 on
>> master, but I it should be fine. I use the same commit as
>> emacs-next-tree-sitter in my local tree-sitter+pgtk emacs package and
>> everything seems to work for me.
>>
>> WDYT?
>
> Personally, the closer to master, the better (and the simpler). What you
> propose, inheritance of pgtk from tree-sitter, fits me well.

Ok, I changed the inheritance order, so now non-wayland users can have
tree-sitter without pgtk and wayland pgtk users will have tree-sitter as
well :)

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Emacs next variants

[Andrew Tropin]

On 2023-03-10 19:24, Cayetano Santos wrote:

>>ven. 10 mars 2023 at 19:14, Simon Tournier  wrote:
>
>> Hi,
>>
>> On Fri, 10 Mar 2023 at 17:59, John Kehayias
>>  wrote:
>>
>>> During this discussion some changes were made to this inheritance structure 
>>> in
>>>
>>> <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=b4c64ddce44bb31332784c3f8e037bd565194604>
>>>
>>> and
>>>
>>> <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=070c335a91d5c245f0360e12c794e9109f9faaf1>
>>
>> Thanks for pointing that.  From my understanding, it does not change
>> what Cayetanos is raising: emacs-next-tree-sitter is built using
>> '--with-pgtk'.  In fact, the package emacs-next-tree-sitter is built
>> using the master branch (Emacs 30 unbranched yet) with tree-sitter
>> *and* pgtk support.
>>
>> Cheers,
>> simon
>
> As for the NEWS-29 file:
>
> "Running this configuration on X is known to have problems, such as
> undesirable frame positioning and various issues with keyboard input of
> sequences such as 'C-;' and 'C-S-u'."
>
> C.

I haven't used X for a while, but if it's still the case for 30 version,
I guess we can inherit pgtk from tree-sitter.

This will update emacs-next-pgtk from emacs-29 to somewhere near 30 on
master, but I it should be fine. I use the same commit as
emacs-next-tree-sitter in my local tree-sitter+pgtk emacs package and
everything seems to work for me.

WDYT?

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Emacs next variants

[Andrew Tropin]

On 2023-03-10 19:14, Simon Tournier wrote:

> Hi,
>
> On Fri, 10 Mar 2023 at 17:59, John Kehayias
>  wrote:
>
>> During this discussion some changes were made to this inheritance structure 
>> in
>>
>> <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=b4c64ddce44bb31332784c3f8e037bd565194604>
>>
>> and
>>
>> <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=070c335a91d5c245f0360e12c794e9109f9faaf1>
>
> Thanks for pointing that.  From my understanding, it does not change
> what Cayetanos is raising: emacs-next-tree-sitter is built using
> '--with-pgtk'.  In fact, the package emacs-next-tree-sitter is built
> using the master branch (Emacs 30 unbranched yet) with tree-sitter
> *and* pgtk support.

Hi everyone!

Also, CCed Liliana.

Will share my motivation behind this desicion below:

After a separation of emacs-next-tree-sitter 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=420cf2bf2a

I heard a few complains from wayland users that now they have to choose
between pgtk emacs or tree-sitter emacs (which runs only under xwayland
and is very blurry) and because I didn't faced any issues with pgtk on
X, I think it's more inclusive to inherit tree-sitter from pgtk.

The other option is to have two tree-sitter versions, but I suspect this
way we will get a combinatorical explosion soon :)

Have a nice weekend, everyone!

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: branch master updated: gnu: emacs: Add TREE_SITTER_GRAMMAR_PATH support.

[Andrew Tropin]

On 2023-02-12 01:14, Ludovic Courtès wrote:

> Hi,
>
> Andrew Tropin  skribis:
>
>> On 2023-02-11 16:35, Andrew Tropin wrote:
>
> [...]
>
>>>> The change to guix-emacs.el is pretty impactful here since that affects
>>>> all the emacs packages including emacs-minimal I think.
>>>>
>>>> If I've understood your comment correctly, that does seem pretty
>>>> wasteful since those rebuilds because of the changed emacs-minimal won't
>>>> have any affect since it's version 28 and not 29, right? I think
>>>> applying this change to just emacs-next would have been possible.
>>>
>>> It could be applied to emacs-next only and we could move it to emacs
>>> later when it updated to 29, but I checked guix refresh --list-dependent
>>> emacs and it shown less than 100 packages so I decided to apply it
>>> straight to emacs, but I forgot that emacs-minimal is inherited from
>>> emacs and I guess you are right and it will affect all the emacs
>>> packages.  Anything we would like to do about it right now?
>>
>> Let's keep it as it is and I'll store it in mind for the next time.
>
> Right.
>
>> There is an idea to update guix refresh --list-dependent to handle the
>> case with inherited packages as well.  WDYT?
>
> Unfortunately, it’s not possible because inheritance info isn’t
> available at run time.
>
> However, peer review and <https://qa.guix.gnu.org> should be able to
> catch it.  No big deal, but next time we’ll know.

I need to figure out how to use qa service, it seems the patch
https://yhetil.org/87edqxri41....@trop.in

is not recognized by
https://qa.guix.gnu.org/issue/49946

Probably it relies on subject for extracting apropriate patches for CI?

Will need to take a look at the source code, thank you for the idea. 

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: branch master updated: gnu: emacs: Add TREE_SITTER_GRAMMAR_PATH support.

[Andrew Tropin]

On 2023-02-11 16:35, Andrew Tropin wrote:

> On 2023-02-11 11:29, Christopher Baines wrote:
>
>> guix-comm...@gnu.org writes:
>>
>>> This is an automated email from the git hooks/post-receive script.
>>>
>>> abcdw pushed a commit to branch master
>>> in repository guix.
>>>
>>> The following commit(s) were added to refs/heads/master by this push:
>>>  new c77a3d4554 gnu: emacs: Add TREE_SITTER_GRAMMAR_PATH support.
>>> c77a3d4554 is described below
>>>
>>> commit c77a3d4554175ee5320ccc713aa21b1ba3e6b8a3
>>> Author: Andrew Tropin 
>>> AuthorDate: Fri Feb 10 12:32:12 2023 +0400
>>>
>>> gnu: emacs: Add TREE_SITTER_GRAMMAR_PATH support.
>>> 
>>> gnu/packages/emacs.scm (emacs)[native-search-paths]: Add a search-path 
>>> for
>>> tree-sitter grammars.
>>> gnu/packages/aux-files/emacs/guix-emacs.el: Add directories from
>>> TREE_SITTER_GRAMMAR_PATH to treesit-extra-load-path.
>>> ---
>>>  gnu/packages/aux-files/emacs/guix-emacs.el |  7 +++
>>>  gnu/packages/emacs.scm | 10 +-
>>>  2 files changed, 16 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/gnu/packages/aux-files/emacs/guix-emacs.el 
>>> b/gnu/packages/aux-files/emacs/guix-emacs.el
>>> index 56dbcb8d67..708093267d 100644
>>> --- a/gnu/packages/aux-files/emacs/guix-emacs.el
>>> +++ b/gnu/packages/aux-files/emacs/guix-emacs.el
>>> @@ -76,6 +76,13 @@ The files in the list do not have extensions (.el, 
>>> .elc)."
>>> (when (file-directory-p pkg-dir)
>>>   (package-load-descriptor pkg-dir)))
>>>  
>>> +;; If emacs built with tree-sitter, read the value of the environment 
>>> variable
>>> +;; to make tree-sitter grammars available in emacs out-of-the-box.
>>> +(with-eval-after-load 'treesit
>>> +  (when-let ((grammar-path (getenv "TREE_SITTER_GRAMMAR_PATH")))
>>> +(mapcar (lambda (x) (add-to-list 'treesit-extra-load-path x))
>>> +(split-string grammar-path ":"
>>> +
>>>  (provide 'guix-emacs)
>>>  
>>>  ;;; guix-emacs.el ends here
>>> diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
>>> index 4ce41deb88..b6a66bafac 100644
>>> --- a/gnu/packages/emacs.scm
>>> +++ b/gnu/packages/emacs.scm
>>> @@ -367,7 +367,15 @@
>>>  (files '("lib/emacs/native-site-lisp")))
>>> (search-path-specification
>>>  (variable "INFOPATH")
>>> -(files '("share/info")
>>> +(files '("share/info")))
>>> +   ;; tree-sitter support is not yet available in emacs 28, but 
>>> this
>>> +   ;; search path won't harm and also will be beneficial for
>>> +   ;; emacs-next and other emacs-* packages, which have tree-sitter
>>> +   ;; support enabled.  Please, remove this comment, when emacs
>>> +   ;; package is updated to 29.
>>> +   (search-path-specification
>>> +(variable "TREE_SITTER_GRAMMAR_PATH")
>>> +(files '("lib/tree-sitter")
>>>  
>>>  (home-page "https://www.gnu.org/software/emacs/;)
>>>  (synopsis "The extensible, customizable, self-documenting text editor")
>>
>> The change to guix-emacs.el is pretty impactful here since that affects
>> all the emacs packages including emacs-minimal I think.
>>
>> If I've understood your comment correctly, that does seem pretty
>> wasteful since those rebuilds because of the changed emacs-minimal won't
>> have any affect since it's version 28 and not 29, right? I think
>> applying this change to just emacs-next would have been possible.
>
> It could be applied to emacs-next only and we could move it to emacs
> later when it updated to 29, but I checked guix refresh --list-dependent
> emacs and it shown less than 100 packages so I decided to apply it
> straight to emacs, but I forgot that emacs-minimal is inherited from
> emacs and I guess you are right and it will affect all the emacs
> packages.  Anything we would like to do about it right now?

Let's keep it as it is and I'll store it in mind for the next time.

There is an idea to update guix refresh --list-dependent to handle the
case with inherited packages as well.  WDYT?

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: branch master updated: gnu: emacs: Add TREE_SITTER_GRAMMAR_PATH support.

[Andrew Tropin]

On 2023-02-11 11:29, Christopher Baines wrote:

> guix-comm...@gnu.org writes:
>
>> This is an automated email from the git hooks/post-receive script.
>>
>> abcdw pushed a commit to branch master
>> in repository guix.
>>
>> The following commit(s) were added to refs/heads/master by this push:
>>  new c77a3d4554 gnu: emacs: Add TREE_SITTER_GRAMMAR_PATH support.
>> c77a3d4554 is described below
>>
>> commit c77a3d4554175ee5320ccc713aa21b1ba3e6b8a3
>> Author: Andrew Tropin 
>> AuthorDate: Fri Feb 10 12:32:12 2023 +0400
>>
>> gnu: emacs: Add TREE_SITTER_GRAMMAR_PATH support.
>> 
>> gnu/packages/emacs.scm (emacs)[native-search-paths]: Add a search-path 
>> for
>> tree-sitter grammars.
>> gnu/packages/aux-files/emacs/guix-emacs.el: Add directories from
>> TREE_SITTER_GRAMMAR_PATH to treesit-extra-load-path.
>> ---
>>  gnu/packages/aux-files/emacs/guix-emacs.el |  7 +++
>>  gnu/packages/emacs.scm | 10 +-
>>  2 files changed, 16 insertions(+), 1 deletion(-)
>>
>> diff --git a/gnu/packages/aux-files/emacs/guix-emacs.el 
>> b/gnu/packages/aux-files/emacs/guix-emacs.el
>> index 56dbcb8d67..708093267d 100644
>> --- a/gnu/packages/aux-files/emacs/guix-emacs.el
>> +++ b/gnu/packages/aux-files/emacs/guix-emacs.el
>> @@ -76,6 +76,13 @@ The files in the list do not have extensions (.el, .elc)."
>> (when (file-directory-p pkg-dir)
>>   (package-load-descriptor pkg-dir)))
>>  
>> +;; If emacs built with tree-sitter, read the value of the environment 
>> variable
>> +;; to make tree-sitter grammars available in emacs out-of-the-box.
>> +(with-eval-after-load 'treesit
>> +  (when-let ((grammar-path (getenv "TREE_SITTER_GRAMMAR_PATH")))
>> +(mapcar (lambda (x) (add-to-list 'treesit-extra-load-path x))
>> +(split-string grammar-path ":"
>> +
>>  (provide 'guix-emacs)
>>  
>>  ;;; guix-emacs.el ends here
>> diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
>> index 4ce41deb88..b6a66bafac 100644
>> --- a/gnu/packages/emacs.scm
>> +++ b/gnu/packages/emacs.scm
>> @@ -367,7 +367,15 @@
>>  (files '("lib/emacs/native-site-lisp")))
>> (search-path-specification
>>  (variable "INFOPATH")
>> -(files '("share/info")
>> +(files '("share/info")))
>> +   ;; tree-sitter support is not yet available in emacs 28, but this
>> +   ;; search path won't harm and also will be beneficial for
>> +   ;; emacs-next and other emacs-* packages, which have tree-sitter
>> +   ;; support enabled.  Please, remove this comment, when emacs
>> +   ;; package is updated to 29.
>> +   (search-path-specification
>> +(variable "TREE_SITTER_GRAMMAR_PATH")
>> +(files '("lib/tree-sitter")
>>  
>>  (home-page "https://www.gnu.org/software/emacs/;)
>>  (synopsis "The extensible, customizable, self-documenting text editor")
>
> The change to guix-emacs.el is pretty impactful here since that affects
> all the emacs packages including emacs-minimal I think.
>
> If I've understood your comment correctly, that does seem pretty
> wasteful since those rebuilds because of the changed emacs-minimal won't
> have any affect since it's version 28 and not 29, right? I think
> applying this change to just emacs-next would have been possible.

It could be applied to emacs-next only and we could move it to emacs
later when it updated to 29, but I checked guix refresh --list-dependent
emacs and it shown less than 100 packages so I decided to apply it
straight to emacs, but I forgot that emacs-minimal is inherited from
emacs and I guess you are right and it will affect all the emacs
packages.  Anything we would like to do about it right now?

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Andrew Tropin]

On 2022-12-20 09:16, Mekeor Melire wrote:

> 2022-12-18 09:11 liliana.prik...@gmail.com:
>
>> I think we should be able to build an Emacs service in Guix Home that can 
>> manage init.el. As a workaround, use-package should also have a :when 
>> clause, so you can use :when (featurep 'some-package-autoloads) if you're 
>> unsure whether 'some-package is actually installed. This makes your init 
>> file a little more resilient and is particularly useful with pure shells.
>
> =guix home import= for init.el is a great idea! (See below for use-cases.)
>
> And yes, =:when (featurep 'some-package-autoloads)= is a workaround that 
> makes 
> init.el files loadable even if respective packages are not available. But the 
> submitted code aims to enable you to install needed emacs-packages so that 
> such a restricting workaround is not needed.
>
>> Given the caveats, I would rather like to see an Emacs Lisp based script 
>> that mocks use-package and generates a manifest by evaluting init.el. This 
>> should give you more correct results. It's not a bad idea per se, but as-is, 
>> I think it would better be maintained in your own channel before 
>> upstreaming.
>
> Problem is that in cases where needed packages are not installed and the user 
> did not add =:when (featurep 'foo)= everywhere, it's possible that evaluating 
> init.el will fail because of some package not being available. Thus, IMHO, we 
> can't rely on Emacs to evaluate the init.el. But we could use Emacs to expand 
> the (use-package) macros inside init.el. But I doubt that it's worth it. I 
> rather think it's easier to use Guile to parse invocations of =require= and 
> =use-package=.
>
>> For upstreaming, I see two potential paths. The first one would be 
>> integration to `guix home import', which Andrew Tropin (CC'd) could probably 
>> tell you more on. The second would be integration into `guix package' as a 
>> callable function/command line argument, but IMHO that's less likely to 
>> pass.
>
> All in all, I think there are three use-cases:
>
> - If you want Guix Home to handle the installation of emacs- packages, there 
>   should be =guix home import= to automatically install those packages, as 
>   resulting from early- and init.el files.

guix home import doesn't install anything, it only generates a configuration.

>
> - If you simply want to install all emacs- packages once per CLI, there 
> should 
>   be =guix package --install-from-elisp-file=~/.emacs.d/init.el= and similar 
>   CLI-arguments or -commands, such as --install-from-elisp-expression, 
>   --install-from-elisp-init-files. There could also be --fit-to-elisp- 
>   variants which not only install packages, but also remove redundant, unused 
>   emacs-* packages.

I don't think we want a separate tricky flags here.  Especially we don't
want some implicit logic removing unused packages.  Just
--8<---cut here---start->8---
guix package --install-from-expression=\
((@ (mekeor emacs-helper) generate-package-from-elisp) \
 #:elisp (local-file "./init.el"))
--8<---cut here---end--->8---
should be enough.  If you want to be sure unused packages are not
installed just don't use imperative guix package and maintain you
configuration in declarative manner.

>
> - If you want to use a manifest.scm for your Guix user-profile and
> import appropriate emacs- therein, there should be Guile modules and
> functions which allow to do so, as the submitted code does. Those
> modules could also be used with =guix package -e=.
>
> And in all three cases, your early- and init.el files might load packages via 
> =require= or =use-package= at least.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Andrew Tropin]

On 2022-12-20 09:45, Mekeor Melire wrote:

> 2022-12-19 14:15 and...@trop.in:
>
>> On 2022-12-18 09:11, Liliana Marie Prikler wrote:
>>
>> > Am Sonntag, dem 18.12.2022 um 01:54 + schrieb Mekeor Melire:
>
>> I'm neither the author, nor the user of guix home import, however I think it 
>> could be a good place for such a functionality, but I would suggest to 
>> maintain this helper functions for a while in a personal channel, mature it 
>> and revisit this question later.
>
> Good idea. But separating this into a personal channel could also lead to the 
> feature being forgotten.
>
>> To make a solution more robust and complete, you can take a look at 
>> straight.el and how it redefines use-package-ensure-function and do 
>> something similiar to generate a list of packages for guix. Another detail 
>> is that use-package accepts a symbol value for :ensure and you can write 
>> something like:
>>
>> ;; (setq use-package-always-ensure t) ; as an alternative to :ensure t
>> (use-package vertico
>>   :ensure t
>>   ...)
>>
>> (use-package vertico-directory
>>   :ensure vertico
>>   ...)
>
> True! The parser should consider the :ensure keyword.
>
>> This way you won't need a concept of "blocked" packages.
>
> It'd still be good to have such a concept in order to block packages that 
> won't be used on Guix-driven system. For example:
>
> #+begin_src elisp
> (when (this-is-not-a-guix-driven-system)
>   (use-package some-package-that-is-not-packaged-for-guix))
>
> ;; or equivalently
>
> (use-package some-package-that-is-not-packaged-for-guix
>   :when (this-is-not-a-guix-driven-system))
> #+end_src
>
>> One more idea: make a function which accepts file-like/origin object instead 
>> of string and generates a package with propagated-dependencies based on the 
>> content of source code provided as an argument.
>
> You mean something like this?:
>
> #+begin_src scheme
> (define-public my-emacs
>   (emacs-from-init
> :custom-emacs-package emacs-with-athena-instead-of-gtk
> :init "/home/user/.emacs.d/init.el"))
> #+end_src

I meant something like this:

--8<---cut here---start->8---
(package-propagating-guix-packages-extracted-from-elisp-configuration
 ;; or just (local-file "./emacs/init.el") or maybe even a remote
 ;; repository with emacs configuration.
 #:configuration (local-file "./emacs/configuration/directory"
 #:recursive? #t))
--8<---cut here---end--->8---

>
> By the way, this won't be a "pure" package. When using 
> =emacsWithPackagesFromUsePackage= feature from nix-community's emacs-overlay, 
> I needed to pass an --impure flag.
>
>> Personally, with my emacs config I do the things vice versa: I have elisp 
>> code in scheme files with a list of explicit dependencies:
>>
>> https://git.sr.ht/~abcdw/rde/tree/b57387f2/src/rde/features/emacs-xyz.scm#L946
>
> Interesting!

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Proof of Concept: Import Emacs' use-packaged packages into Guix' manifest.scm

[Andrew Tropin]

On 2022-12-18 09:11, Liliana Marie Prikler wrote:

> Am Sonntag, dem 18.12.2022 um 01:54 + schrieb Mekeor Melire:
>> Nevertheless, for me, personally, it's pretty neat and handy to 
>> use, because I don't need to maintain the list of emacs-packages 
>> in two places. I also think that it could come pretty handy for 
>> many others, at least in order to initialize their user-profile, 
>> by running something like ~guix package -e '(some-magic 
>> "/home/user/.emacs.d/init.el")'~.
> I think we should be able to build an Emacs service in Guix Home that
> can manage init.el.  As a workaround, use-package should also have a
> :when clause, so you can use :when (featurep 'some-package-autoloads)
> if you're unsure whether 'some-package is actually installed.  This
> makes your init file a little more resilient and is particularly useful
> with pure shells.
>
>> What do you think? Should this go into a separate, private 
>> channel? Into the Guix Cookbook? Into Guix, if so, then probably 
>> with lots of changes? Should it just stay here, in this mailing 
>> list thread? Or do you think this is just a bad idea in general?
> Given the caveats, I would rather like to see an Emacs Lisp based
> script that mocks use-package and generates a manifest by evaluting
> init.el.  This should give you more correct results.  It's not a bad
> idea per se, but as-is, I think it would better be maintained in your
> own channel before upstreaming.
>
> For upstreaming, I see two potential paths.  The first one would be
> integration to `guix home import', which Andrew Tropin (CC'd) could
> probably tell you more on.

I'm neither the author, nor the user of guix home import, however I
think it could be a good place for such a functionality, but I would
suggest to maintain this helper functions for a while in a personal
channel, mature it and revisit this question later.

To make a solution more robust and complete, you can take a look at
straight.el and how it redefines use-package-ensure-function and do
something similiar to generate a list of packages for guix.  Another
detail is that use-package accepts a symbol value for :ensure and you
can write something like:

--8<---cut here---start->8---
;; (setq use-package-always-ensure t) ; as an alternative to :ensure t
(use-package vertico
  :ensure t
  ...)

(use-package vertico-directory
  :ensure vertico
  ...)
--8<---cut here---end--->8---

This way you won't need a concept of "blocked" packages.

One more idea: make a function which accepts file-like/origin object
instead of string and generates a package with propagated-dependencies
based on the content of source code provided as an argument.


Personally, with my emacs config I do the things vice versa: I have
elisp code in scheme files with a list of explicit dependencies:

https://git.sr.ht/~abcdw/rde/tree/b57387f2/src/rde/features/emacs-xyz.scm#L946

Nevertheless, your idea with use-package looks good to me.

> The second would be integration into `guix package' as a callable
> function/command line argument, but IMHO that's less likely to pass.
>
>
> Cheers

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Creating an Emacs Home Configuration Service

[Andrew Tropin]

On 2022-10-19 10:53, Zain Jabbar wrote:

> Aloha All,
>
> Super awesome to hear from you! I'm quite star stuck.
>
> Thank you for showcasing Andrew Tropin's rde project. I believe the
> =features= abstraction have potential and make more intuitive sense
> for the design of configurable programs. There is a lot for me to
> learn from this design choice.
>
> As it stands, =features= are not in Guix proper, are there plans to
> merge them?

There was no plan to merge this mechanism to Guix proper and I think
it's actually good to maintain this as a separate project/guix channel,
however it is discussable.  Features itself are quite opinionated and
doesn't fit general-purpose nature of the Guix IMO, so I don't think we
(Guix devs) want to merge them.

> How will they end up relating to the existing home services feature
> set?

rde features are basically wrappers around home and system services,
which allows to share values among those services, also it allows to
implement polymorphic behavior.

You can trace origins somewhere in rde-devel mailing list:
https://lists.sr.ht/~abcdw/rde-devel/%3C87sg56g97i.fsf%40trop.in%3E

Because rde features are a user-facing interface, and services mechanism
is slightly hidden underneath, rde's home and system services are less
suitable for end-user, but more flexible.  We (rde devs) usually don't
use records, which help to define rigid config structure, provide
autocompletion, field existence and type checks, and other benifits, but
provide sxml or other sexp based representation of underlying
configuration formats.

BTW, there is an emacs-home-service-type in rde:
https://git.sr.ht/~abcdw/rde/tree/59a2c1ef615aac7c5dac08660bd00ea5873e77b7/rde/home/services/emacs.scm#L20

and you can find various usage examples in people's configuration or in
rde/feature/emacs* modules.
https://git.sr.ht/~krevedkokun/dotfiles/tree/master/item/config/home/yggdrasil/emacs.scm
https://git.sr.ht/~akagi/guixrc/tree/master/item/magi/home/emacs.scm
https://git.sr.ht/~abcdw/rde/tree/master/item/rde/features/emacs.scm
https://git.sr.ht/~abcdw/rde/tree/master/item/rde/features/emacs-xyz.scm

>
> On Wed, Oct 19, 2022 at 5:36 AM Ludovic Courtès  wrote:
>>
>> Hi Zain, and welcome!
>>
>> Zain Jabbar  skribis:
>>
>> > Running =guix home search emacs= returns nothing. I also could not find an
>> > email using =C-u M-x debbugs-gnu= about an Emacs configuration service.
>> >
>> > This is my first email to this mailing address. Please give me pointers on
>> > formatting and further improvements.
>> >
>> > I have attempted to make an =emacs-home-service-type= so that it is
>> > possible to configure Emacs using Guix home. This code is extremely
>> > preliminary hence I don't even think it is worth sending as a patch. Also I
>> > have never worked on a multi person Git project before and do not know how
>> > to solve the keyring error I get when using guix pull. I will outline what
>> > my code does and what features I would like to add.
>>
>> I am all for something like you describe, and the code you sent may be
>> good starting point!
>>
>> The rde project¹ by Andrew Tropin et al. may be a good source of
>> inspiration.  The “features” abstraction in particular seems to be
>> well-suited for Emacs.  But overall it’s reasonable to start small, with
>> a low-level approach to combine and configure Emacs packages.
>>
>> Thanks,
>> Ludo’.
>>
>> ¹ https://trop.in/rde/manual

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: An apology

[Andrew Tropin]

On 2022-10-13 09:36, Felix Lechner wrote:

> Hi Andrew,
>
> Please accept my apologies for sending the message below. Aside from
> being impolite, my note was also ill-timed given your newly-won status
> as a committer. I could have hardly been more tone-deaf. If at all, I
> should have written in private.
>
> While not a great explanation, I occasionally spend time with
> scientists and engineers working on weapons. Over the years, I have
> become cynical about the progress of technology. It was not the first
> time that I have been vocal in technical forums about embracing life
> rather than taking it.
>
> I felt sorry for several weeks and hope you can forgive me. May this
> follow-up in public remove any stain from
> your good name.

No worries, I'm not offended or anything :) I just have a huge email
backlog and didn't allocate the time to reply yet, sorry.  Also, have an
additional time wastes due to unfortunate events happening in my country
and for now I usually read, mark as todo and skip messages, which
don't block anyone.

>
> Thanks for Guix Home!

My pleasure!)

>
> Sincerely,
> Felix
>
>
> -- Forwarded message -
> From: Felix Lechner 
> Date: Thu, Aug 11, 2022 at 8:09 AM
> Subject: Re: [POSTMORTEM] Subkey is not authorized by .guix-authorizations
> To: Guix Devel 
>
>
> Hi,
>
> On Thu, Aug 11, 2022 at 7:27 AM Andrew Tropin  wrote:
>>
>> Re: [POSTMORTEM]
>
> I have likewise used those words to describe concluding reports or to
> communicate lessons learned, but upon reflection I now prefer
> "incident summary" or "debrief". [1] Since both of my suggested
> replacements are associated with the military, they are also not great
> examples of favoring life over death, but at least the parties are not
> yet in the morgue, so there is hope.
>
> Long live Guix!
>
> Kind regards
> Felix Lechner
>
> [1] "debriefing strategies maximize ... the collective experience",
> https://en.wikipedia.org/wiki/Debriefing

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: [POSTMORTEM] Subkey is not authorized by .guix-authorizations

[Andrew Tropin]

On 2022-09-02 15:23, Ludovic Courtès wrote:

> Hello!
>
> I’m late to the party, but thanks a lot for sending this analysis!
>
> Andrew Tropin  skribis:
>
>> * What could be done better?
>> - guix pull could be done from local checkout, before pushing.
>
> Setting a pre-push hook that invokes ‘guix git authenticate’, as
> recommended in the manual (info "(guix) Commit Access"), should be
> enough: ‘git push’ would just fail in that situation.

For some reason I thought it does git verify-commit, which I used
manually to check if commit is signed, but it does make authenticate,
which of course works the other way.  Missed it, my bad.

I have elaborated on this topic a little more in the manual.
From e510ea1595c54bec788485f0638967d457afaf3d Mon Sep 17 00:00:00 2001
From: Andrew Tropin 
Date: Mon, 5 Sep 2022 09:46:23 +0300
Subject: [PATCH] doc: Add more info about commits signature local
 verification.

* doc/contributing.texi (Commit Access): Add more info about commits signature
local verification.
---
 doc/contributing.texi | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index b1d236c011..17a54f94cc 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -1627,14 +1627,23 @@ git config commit.gpgsign true
 git config user.signingkey CABBA6EA1DC0FF33
 @end example
 
-You can prevent yourself from accidentally pushing unsigned commits to
-Savannah by using the pre-push Git hook located at
-@file{etc/git/pre-push}:
+To check that commits are signed with correct key, use:
+
+@example
+make authenticate
+@end example
+
+You can prevent yourself from accidentally pushing unsigned or signed
+with the wrong key commits to Savannah by using the pre-push Git hook
+located at @file{etc/git/pre-push}:
 
 @example
 cp etc/git/pre-push .git/hooks/pre-push
 @end example
 
+It additionally calls @code{make check-channel-news} to be sure
+@file{news.scm} file is correct.
+
 @subsection Commit Policy
 
 If you get commit access, please make sure to follow
-- 
2.37.2


>> - Accept subkey on guix pull if master key is in .guix-authorizations.
>
> Reported at <https://issues.guix.gnu.org/57091>.
>
>> - Add pre-push hook, which checks authorization on Savannah.
>
> That one is difficult: Guix is not installed on those machines.
>
> Another option would be to push to a different machine, one that we
> control, and make Savannah a mirror of that one.

It can work, but looks fragile.

>
> Thoughts?

Let's ask savannah admins if it possible to install guix on those
machines and add pre-receive/update hook?  If not, we will look for
other options.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Welcome to our new committer!

[Andrew Tropin]

On 2022-08-15 02:40, Joshua Branson wrote:

> I am a little late to the party, but congrats Androw!

Thank you ;)

>
> Your hacking videos on guix are awesome!

My pleasure!)

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

[POSTMORTEM] Subkey is not authorized by .guix-authorizations

[Andrew Tropin]

* Summary
On 2022-08-06 the commit 3946540[fn:1] was pushed and lead to failing
guix pull:

--8<---cut here---start->8---
guix pull: error: commit 39465409f0481f27d252ce25d2b02d3f5cbc6723 not
signed by an authorized key: 2841 9AC6 5038 7440 C7E9 2FFA 2208 D209
58C1 DEB0
--8<---cut here---end--->8---

It was discovered and reported to IRC almost immediately by a few
people.  The commit itself was signed and benign[fn:2], but it was signed with
subkey.  While primary key was added to .guix-authorizations, guix pull
still rejected commit signed with subkey.

From the point commit pushed there is no easy way to recover guix
pull.  nckx contacted savannah admins and a few hours later master
branch was reset to the state before 3946540 was pushed.

* Impact
- guix pull of latest commit from master branch couldn't be done for a
  few hours, the possible problem of such DoS is known[fn:3].

* What could be done better?
- guix pull could be done from local checkout, before pushing.
- First commit by a fresh commiter could be pushed on a weekday, after
  checking if maintainers and admins are present.

* What to do after?
- Accept subkey on guix pull if master key is in .guix-authorizations.
- Add tip to Commit Access section about pull from local checkout.
- Add pre-push hook, which checks authorization on Savannah.

* Footnotes

[fn:1] 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=39465409f0481f27d252ce25d2b02d3f5cbc6723

[fn:2] https://lists.gnu.org/archive/html/help-guix/2022-08/msg00073.html

[fn:3] https://lists.gnu.org/archive/html/guix-devel/2021-03/msg00156.html


-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Welcome to our new committer!

[Andrew Tropin]

On 2022-08-05 23:07, Tobias Geerinckx-Rice wrote:

> Hi Andrew,
>
> A big fat welcome from me as well.

Yay!)

>
> Savannah UI being what it is, I'm almost completely certain that I
> managed to make you a member of the ‘GNU Guix’ organisation there. 
> You should be able to push to the Git repository.

Thank you, I see myself in the group and as you probably already know
can push :)

>
> For my own future reference: did you get any automated mails about
> that from Savannah?
>

No automated emails recieved.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Welcome to our new committer!

[Andrew Tropin]

On 2022-08-05 18:59, Efraim Flashner wrote:

> The Guix Maintainer Collective (tm) would like to welcome Andrew Tropin,
> aka abcdw, as our newest committer! I'm sure many of you recognize them
> from their work on Guix Home and their regular videos hacking on Guix,
> among other things.
>
> So join us in welcoming them!

Hi everyone!

You can obtain my GPG key with:
gpg --locate-keys and...@trop.in

Or from savannah:
https://savannah.gnu.org/users/abcdw

Don't hesitate to CC me to interesting threads or ping me once in a
while!

Have a good weekend, see you in a bit! :)

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Guix home and operating-system

[Andrew Tropin]

On 2022-07-18 11:38, Ludovic Courtès wrote:

> Hi,
>
> Andrew Tropin  skribis:
>
>> I don't remember all the details and where I stopped, but the highlevel
>> idea is following:
>>
>> - Define a system services, which contains (user . home-environment) pairs.
>> - Build home environments on system reconfigure.
>> - Activate home environments on boot.
>
> That would be a nice addition!

For future readers, the work is happenning in #56669
(Message-ID: 63960cf762aec1ed2c4182f49cac66bc37fce2aa.ca...@rdmp.org)

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Guix home and operating-system

[Andrew Tropin]

On 2022-07-06 11:20, Tissevert wrote:

> Hi Guix,
>
> I'm finally having some time to try and put guix on the older machines at home
> and thought I'd start by generating a live CD to show the rest of the family
> what that would look like without having to make any irreversible changes yet.
>
> Meanwhile, as this is a time to clean and rationalize system declarations to
> ease maintaining the various machines, I thought it would be an appropriate
> time to try and start learning about guix home (I came to guix for the
> reproducibility, I'm not going to spend hours on each machine reproducing the
> same user config !).
>
> To my greatest astonishment, I found no way to make guix home configurations
> interact with operating-system declarations. I expected something along the
> lines of a "configuration" or "home" field in the user-account data type, 
> which
> could contain directly a valid guix home configuration or maybe the path to a
> file containing one. At least, I expected to find a "packages" field to allow
> specifying the packages set for a particular user. This is of course necessary
> when building a read-only live image which won't be able to receive
> modification at a later time. More generally, this raised a question in me: 
> why
> go to such length to have a whole declarative system which you can generate in
> advance on each aspect, and then require to launch (stateful !) command lines
> at a later time to alter the configuration of users.
>
> I was discussing that the other night with @unmatched-paren on IRC and was 
> told
> this could be an interesting idea so what do you think ? Is there a good 
> reason
> why this hasn't been implemented ? Would it be very complicated to run the
> equivalent of a guix home at the end of the system generation ? I'd be
> personally interested to work on such a feature but I have absolutely no idea
> where to start and would be glad to receive some pointers if it was deemed
> useful enough that I should spend my time on it.
>
> Now I can think of several ways to do that differently: I suppose the live CD
> could have a system service performing the call to guix home to setup the
> user's environment during the boot. Also, this would not cover user services
> but regarding file configurations, I can think of a way because I'm prone to
> config vertigo these days: there are so many levels where we can alter the
> config, why always delay it ? Packages often contain a default configuration,
> and upon start the program checks half a dozen places for a custom user 
> config:
> in other words why have a bash profile in my home when I could generate a bash
> package which has directly my dream profile in its "default" version in /etc ?
> I could still use ~/.bash_profile for a temporary tweak. Is that something
> people in guix do frequently ? Why ?
>
> Cheers,
>
> Tissevert
>

Hi Alice!

This topic was discussed a few times already, but still not yet
implemented.  Probably the last one was "Guix system with
home-environment" in help-guix mailing list.

I played around with it, did some changes to Guix Home (maybe some small
patches not yet upstreamed, but they are not critical IIRC), but didn't
finish the implementation and postpone it again, still think it's really
valuable feature.

I don't remember all the details and where I stopped, but the highlevel
idea is following:

- Define a system services, which contains (user . home-environment) pairs.
- Build home environments on system reconfigure.
- Activate home environments on boot.

Here are some WIP half an year old code for guix-home-service-type:


home.scm
Description: Binary data

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Teams

[Andrew Tropin]

On 2022-06-05 10:19, Josselin Poiret wrote:

> Hello everyone,
>
> Ricardo Wurmus  writes:
>
>> As a first step I’d suggest collecting teams, setting up the email
>> aliases, and updating the website to show the existing teams.
>
> I think an installer team would be good too (which I would gladly join).
> WDYT of the following teams:
> * Installer (which I'd gladly join);
> * System;
> * Home;
> * Internals?
>
> Maybe that would add too many teams, but I think the first three could
> be pretty useful.
>
> How do we automatically make Mumi understand which team a patch should
> notify?  I've just started using public-inbox/lei and the `dfn:` search
> term is pretty useful, it lets you select only patches that change
> specific files.  For example, `dfn:gnu/installer*` would match all
> patches that touch the installer.
>
> Best,

I'm not in a guix-maintainers yet, but I would like to join Home team.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: guix home: error: rmdir: No such file or directory

[Andrew Tropin]

On 2022-04-09 07:16, Feng Shu wrote:

> feng@Guix ~$ LC_ALL=C ihome-reconfig 
> Cleaning up symlinks from previous home at 
> /gnu/store/m70cycn4wkhqmk85pkh8jxspbnw35sw8-home.
>
> guix home: error: rmdir: No such file or directory

It should be fixed by this commit:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=435e1cef00

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Multiple profiles with Guix Home

[Andrew Tropin]

On 2022-05-24 20:31, Liliana Marie Prikler wrote:

> Hi,
>
> Am Dienstag, dem 24.05.2022 um 14:55 +0300 schrieb Andrew Tropin:
>> On 2022-05-23 19:05, Liliana Marie Prikler wrote:
>> > [...]
>> > I don't think I agree with this choice.  To satisfy both my own use
>> > case of serving profiles in different locations from another and
>> > another issue being raised w.r.t. configuring the location of the
>> > .guix-home profile, I think we should make a triple of location,
>> > optional short name, and manifest (which may be generated from
>> > packages implicitly).  WDYT?
>> > 
>> 
>> This service is intended for profiles managed by Guix Home, so every
>> profile MUST be a part of home-environment (~/.guix-home is a symlink
>> to it).  I don't see any meaningful reasons to make it possible to
>> customize the path inside home-environment.
> Why though?  The decision to restrict Guix Home to dotfiles was already
> a bad one that has since been overturned, so I think we should
> carefully evaluate why "~/.guix-home" even is special.  In my point of
> view, any path that is prefixed with the user's home ought to be fair
> game, as should be constructing intermediate per-user profile symlinks
> in /var/guix.

It's not bad, it had and has its own goals, pros and cons, I found
another design descision, which we think is more intuitive, but still
partially serving original goals and we switched to it.  The disucssion
about ~/.guix-home symlink itself is unrelated to both "dotfiles
question" and my original statement.

All dot/xdg/other files belong to home-environment and no side-effects
are done during the build of home-environment, the only side-effects
happens during activation and $HOME touched only by symlink-manager and
I would like to keep it to be the case, otherwise we will end up with
tons of stateful ad-hoc hacks.

That said, I would like to avoid any Guix Home logic to rely on paths
outside of home-environment.  In case you really need
~/work/my-project/guix-profile to be created for some reason you can
extend home-files-service-type and rely on symlink-manager to do this
dirty job, but the setup-environment script will still source
home-environment/profiles/your-profile-name and won't know anything
about ~/work/my-project/guix-profile.

>> If you want to have profiles like ~/work/my-project/guix-profile or
>> ~/.guix/profiles/my-python-environment managed by Guix Home you can
>> implement home-external-profiles-service-type, which can extended
>> activation service or any other impure tricks, but I would advice
>> against it.  I suggest either manage a profile with
>> home-[additional-]-profiles or manage them externally and load with
>> home-profile-paths/home-profile-loader.
> Pardon me if I was confusing, but I meant to have one service defining
> the existence of ~/work/my-project/guix-profile (that being home-
> profiles-service-type) and another to load it (that being home-profile-
> loader-service-type).  Admittedly, the existing way of specifying a
> profile that is loaded becomes more work then, so perhaps we can add
> some syntactic sugar to that, so that both services get extended at
> once.
>
>> > Considering the above, I think a rough roadmap would be:
>> > 1. Implementing home-profiles-service-type (to build the profiles)
>> > 2. Implementing home-profile-loader-service-type
>> 
>> This one looks simplier and also independent from #1, so I would
>> recommend to start with it.  Also, it's very likely that
>> home-profiles-service-type will be extending
>> home-profile-loader-service-type
> I thought about it for some while, but I really don't think either is
> easier than the other, particularly in the way I described it, where
> home-profiles-service-type and home-profile-loader-service-type are
> orthogonal to each other.
>
>> > 3. ???
>> > 4. Deprecate the existing home-profile-service-type in favor of the
>> > new profile service type pair and/or implement it in terms of it.
>> > where (1) and (2) could be done by two people/teams in parallel.
>> 
>> The migration should be quite simple here.
>> 
>> JFYI: The design of Guix Home is flexible, essential services can be
>> completely customized, even symlink-manager can be removed or
>> substituted with something else (for example to make a read-only home
>> workflow proposed by Julien Lepiller in guix-home-manager).  This is
>> also used in rde to substitute home-shell-profile-service-type with
>> alternative implementation:
>> https://git.sr.ht/~abcdw/rde/tree/master/item/rde/features.scm#L234
> I'm not sure if I'm that fond of this design choic

Re: Multiple profiles with Guix Home

[Andrew Tropin]

On 2022-05-23 19:05, Liliana Marie Prikler wrote:

> Hi,
>
> Am Montag, dem 23.05.2022 um 16:14 +0300 schrieb Andrew Tropin:
>> The discussion seems too heated and bloated, it's hard to reasonably
>> address arguments mentioned around, so I'll just post some thoughts
>> and a possible way to somehow proceed.
>> 
>> I suggest to split the bigger idea into smaller pieces, play with the
>> implementation locally/in fork/branch and see how it goes:
>> 
>> 1. home-profiles-paths-service-type.  It will allow to add code for
>> sourcing profiles in setup-environment script and thus implement
>> workflows with multiple profiles.  Such profiles can be managed
>> externally or in the future built as a part of home environment.
> How about home-profile-loader-service-type as a name instead?  That
> would imply that it's purpose is to load profiles.

Looks ok for me.

>> 2. home-[additional-]profiles-service-type.  It will allow to build
>> profiles from list of packages, optionally add a profile to
>> home-profiles-paths.  It will make ~/.guix-
>> home/profiles/{emacs,web,etc}
>> 
>> To make it possible for other service to utilize multiple profiles,
>> this service will be extandable with values like that:
>> 
>> `((default . ,(list curl wget))
>>   (web . ,(list browser-ad-block-plugin))
>>   (emacs . ,(list emacs emacs-cider emacs-modus-themes)))
> I don't think I agree with this choice.  To satisfy both my own use
> case of serving profiles in different locations from another and
> another issue being raised w.r.t. configuring the location of the
> .guix-home profile, I think we should make a triple of location,
> optional short name, and manifest (which may be generated from packages
> implicitly).  WDYT?
>

This service is intended for profiles managed by Guix Home, so every
profile MUST be a part of home-environment (~/.guix-home is a symlink to
it).  I don't see any meaningful reasons to make it possible to
customize the path inside home-environment.

If you want to have profiles like ~/work/my-project/guix-profile or
~/.guix/profiles/my-python-environment managed by Guix Home you can
implement home-external-profiles-service-type, which can extended
activation service or any other impure tricks, but I would advice
against it.  I suggest either manage a profile with
home-[additional-]-profiles or manage them externally and load with
home-profile-paths/home-profile-loader.

>> 3. Maybe migrate ~/.guix-home/profile to ~/.guix-
>> home/profiles/default.
> Kinda agree, but with the caveat in (2).  Uniformity or chaos should be
> a user choice :)
>
>> I still can see a lot of potential problems related to search paths,
>> however part of them can be solved by duplicating packages in
>> different profiles or using dummy packages like emacs-consumer:
>> https://git.sr.ht/~abcdw/rde/tree/master/item/rde/packages/emacs.scm#L56
> Or by making search paths first class in manifests, as also discussed
> elsewhere.
>
>> [...]
>> Liliana, if you still into it, I suggest to start with something
>> similiar to what I described above, share the draft implementation
>> and intermediate results/impression in a separate thread and continue
>> the further discussion.
> Considering the above, I think a rough roadmap would be:
> 1. Implementing home-profiles-service-type (to build the profiles)
> 2. Implementing home-profile-loader-service-type

This one looks simplier and also independent from #1, so I would
recommend to start with it.  Also, it's very likely that
home-profiles-service-type will be extending
home-profile-loader-service-type

> 3. ???
> 4. Deprecate the existing home-profile-service-type in favor of the new
> profile service type pair and/or implement it in terms of it.
> where (1) and (2) could be done by two people/teams in parallel.

The migration should be quite simple here.

JFYI: The design of Guix Home is flexible, essential services can be
completely customized, even symlink-manager can be removed or
substituted with something else (for example to make a read-only home
workflow proposed by Julien Lepiller in guix-home-manager).  This is
also used in rde to substitute home-shell-profile-service-type with
alternative implementation:
https://git.sr.ht/~abcdw/rde/tree/master/item/rde/features.scm#L234

This way you can experiment with multi-profile approach even without
modifying existing code.

>
> Given that the task has been simplified, I think I might start coding
> on it, but I can't promise any particular deadline.  At the moment,
> both my day job and review work delay any other contributions towards
> Guix.
>
> Cheers

I also advice to treat it as an experiment.  IMO Guix Home should be
relatively conservative,

Re: Multiple profiles with Guix Home

[Andrew Tropin]

On 2021-10-03 12:50, Liliana Marie Prikler wrote:

> Hi Guix,
>
> it's been a while since the discussion of whether or not to collect
> multiple profiles into a single directory [1].  This suggestion takes
> inspiration from that, but goes a vastly different route.  Instead of
> using environment variables to control Guix, it takes advantage of the
> recently added Guix Home, even if it is still a technical preview.
>
> So, what's the proposition?  I suggest we modify home-profile-service-
> type (or add a new service) such that it takes a list of  
> records instead of a list of packages.  This record would be defined as
>
>   (define-record-type*  home-profile
> make-home-profile home-profile? this-home-profile
> (location home-profile-location) ; string, e.g. $HOME/.guix-profile
> (short-name home-profile-short-name) ; string or #f, if given
>  ; construct a symlink in
>  ; /var/guix/.../per-user/
> (manifest %home-profile-manifest) ;  or #f
> (packages home-profile-packages) ; list of  or #f
>  ; fallback for manifest
> (enabled? home-profile-enabled?) ; boolean, default #t
> [...])
>
>   (define (home-profile-manifest home-profile)
> (or (%home-profile-manifest home-profile)
> (and=> (home-profile-packages home-profile) 
>packages->manifest
>
> On init/reconfigure, `guix home' creates/updates all home-profiles
> which have a home-profile-manifest that is not #f and links them to the
> appropriate locations.  It also creates a shell startup script that
> loads those profiles that are enabled?, even if they have no manifest
> (this can be used to e.g. declare a pull profile, which `guix home'
> can't manage).  
>
> Some existing home services would need to be adapted towards this
> multiple profile usage.  For instance, home-fontconfig-service-type
> would need to accept a list of directories, rather than hardcode its
> value.
>
> What do y'all think?
>
> <https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00358.html>
>
>

The discussion seems too heated and bloated, it's hard to reasonably
address arguments mentioned around, so I'll just post some thoughts and
a possible way to somehow proceed.

I suggest to split the bigger idea into smaller pieces, play with the
implementation locally/in fork/branch and see how it goes:

1. home-profiles-paths-service-type.  It will allow to add code for
sourcing profiles in setup-environment script and thus implement
workflows with multiple profiles.  Such profiles can be managed
externally or in the future built as a part of home environment.

2. home-[additional-]profiles-service-type.  It will allow to build
profiles from list of packages, optionally add a profile to
home-profiles-paths.  It will make ~/.guix-home/profiles/{emacs,web,etc}

To make it possible for other service to utilize multiple profiles, this
service will be extandable with values like that:

`((default . ,(list curl wget))
  (web . ,(list browser-ad-block-plugin))
  (emacs . ,(list emacs emacs-cider emacs-modus-themes)))

3. Maybe migrate ~/.guix-home/profile to ~/.guix-home/profiles/default.
  
I still can see a lot of potential problems related to search paths,
however part of them can be solved by duplicating packages in different
profiles or using dummy packages like emacs-consumer:
https://git.sr.ht/~abcdw/rde/tree/master/item/rde/packages/emacs.scm#L56

Also, I can see potential complication of Guix Home in general due to
multiple profiles capabilities and I still not sure that it worth the
benefits mentioned below:

I agree that multiple profiles can be benifitial for both better package
organization/structuring needs and faster build/reconfigure times.

I also see some demand from people requesting such a feature.

Liliana, if you still into it, I suggest to start with something
similiar to what I described above, share the draft implementation and
intermediate results/impression in a separate thread and continue the
further discussion.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Should Guix Home daemonize Shepherd?

[Andrew Tropin]

On 2022-03-12 18:49, Kevin Boulain wrote:

> So, I've done some digging and I'm coming back with two findings :)
>
> First, Guix Home correctly tells the user Shepherd to daemonize itself
> via an 'action'
> (https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services/shepherd.scm#n64)
> but, from my understanding, the daemonization process is missing at
> least a setsid call
> (https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service.scm#n1421),
> see the attached 'shepherd-setsid.patch'. This fixes the Shepherd
> dying when exiting the SSH session or the Shepherd catching the ^C.
> I guess it should also close std{in,out,err} like it's done for the
> regular services
> (https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/service.scm#n806)
> but this answers a part of my initial post.

CCed Leo, Ludovic and Carlo.

>
> Second, elogind (it's required by Guix Home to get the XDG_*
> environment variables and also part of %desktop-services) will remove
> /run/user/$uid when the session ends. 

Actually, XDG_RUNTIME_DIR can be provided not only by elogind, but also
by pam_rundir or something similar, however in general it's true,
runtime dir will be removed when session ends.

> It's standard, but the problem is that Guix Home's
> 'on-first-login-executed' is located there, alongside
> 'shepherd/socket' and probably the other user daemon's sockets. This
> easily results in duplicate services being rerun when the old ones
> haven't been killed because 'KillUserProcesses' is set to 'no' by
> default
> (https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/desktop.scm#n937).
> I don't think it's a bad idea to set KillUserProcesses=no (I remember
> that when this was first introduced a lot of users complained, see for
> example https://github.com/tmux/tmux/issues/428) but now we're in an
> awkward position unless Guix Home users move everything out of
> XDG_RUNTIME_DIR (for example, tmux's socket is in /tmp).
>
> Thoughts? I must admit, I'm not sure how to address the elogind issue,
> XDG_RUNTIME_DIR is ingrained in a lot of places (even in the Shepherd
> https://git.savannah.gnu.org/cgit/shepherd.git/tree/modules/shepherd/support.scm#n284)
> and asking users to override socket flags (and others) for all the
> services they run (if at all possible) sounds a bit counterintuitive.

This is a tough question, faced it when only started to work on Guix
Home.  One idea I had back in the days is to have a possibility to get
lingering user shepherd, which starts on boot, the implementation
doesn't seem trivial so I decided to postpone experiments in this
direction for a better times.  Not sure if it's any perfect, but at
least is something to think about.

> Or am I missing something obvious?
> Detach from the controlling terminal when daemonizing
>
> https://lists.gnu.org/archive/html/guix-devel/2022-03/msg00040.html
>
> diff --git c/modules/shepherd/service.scm w/modules/shepherd/service.scm
> index ad8608b..62f97bc 100644
> --- c/modules/shepherd/service.scm
> +++ w/modules/shepherd/service.scm
> @@ -1420,8 +1420,12 @@ we want to receive these signals."
>(else
> (if (zero? (primitive-fork))
> (begin
> - (catch-system-error (prctl PR_SET_CHILD_SUBREAPER 1))
> - #t)
> + (setsid)
> + (if (zero? (primitive-fork))
> + (begin
> +   (catch-system-error (prctl PR_SET_CHILD_SUBREAPER 1))
> +   #t)
> +     (primitive-exit 0)))
> (primitive-exit 0))
>   (persistency
>"Save the current state of running and non-running services.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: RFC: Configurable placing of the ~/.guix-home symlink

[Andrew Tropin]

On 2022-05-05 06:55, Attila Lendvai wrote:

>> When trying to get a clean $HOME, I see that the ~/.guix-home path is fixed 
>> in
>> the code under gnu/home/*,
>> usually via (string-append (GETENV "HOME") "/.guix-home").
>
> FWIW, i was also surprised that the default is not something under 
> ~/.config/guix/

It also can be problematic, we can't hardcode ~/.config/guix home due to
XDG spec, and at the same time XDG_CONFIG_HOME can be managed by Guix
Home, but also can be set outside, and all the points mentioned above
applicable here as well.

Back in the day, the implementation of Guix Home required a symlink in
home directory, right now due to improvements in symlink-manager and
reconfigure code it's probably not necessary and with a few patches
/var/guix/profiles/per-user/bob/guix-home/ can be used instead.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Multiple profiles with Guix Home

[Andrew Tropin]

On 2022-05-04 15:15, Reza Housseini wrote:

> On 5/4/22 09:01, Maxime Devos wrote:
>> Liliana Marie Prikler schreef op wo 04-05-2022 om 06:16 [+0200]:
>>>> Until the previous mail, I have not seen anything about thematic
>>>> profiles, so I did not have thematic profiles in mind in my
>>>> response.
>>>> Even then, I'm not sure what these thematic profiles are supposed
>>>> to
>>>> solve that is not working around some underlying problem (e.g. slow
>>>> profile building times).
>>> Pierre's "Guix Profiles in Practice" is a 2.5 years old blog post.
>>> If
>>> you can't think of any uses for multiple profiles, you're not the
>>> target audience at this point.
>>>
>> I have seen that blog post.  I do use profiles, albeit with "guix
>> environment" and now "guix shell".  But I have not yet seen any reasons
>> for profile _splitting_.  And if I'm not the target audience, what does
>> that matter?
>>
>> Greetings,
>> Maxime.
>
> A specific use case for profile splitting I see very useful, is e.g. 
> having a profile with all your editor and plugin dependencies and your 
> project specific dependencies. So if you work on a specific project you 
> can merge the two profiles and your linters will not complain about 
> missing dependencies.
>
> I can also imagine more fine grained splitting, for example test and 
> documentation dependencies in separate profiles or even unit test and 
> integration test dependencies split into separate profiles.
>
> At the moment I see no possibilities for even the "easy" use case I 
> mentioned first.
>

I do some work in rde project for reusing guix home infrastructure
outside of Guix Home for making per-project development environments.
https://youtu.be/knRDdhLRY5Y

This allows to have project dependencies including editor, its plugins
and dependencies of plugins and other stuff available for your project,
but not polluting your main profile or interfer with other projects.
https://youtu.be/pS9JBKdAy4Q

Everything is very much WIP, but I'll document all the stuff in
https://trop.in/rde/manual, when it ready.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: RFC: Configurable placing of the ~/.guix-home symlink

[Andrew Tropin]

On 2022-04-29 11:44, EuAndreh wrote:

> Hi Guix!
>
> When trying to get a clean $HOME, I see that the ~/.guix-home path is fixed in
> the code under gnu/home/*,
> usually via (string-append (getenv "HOME") "/.guix-home").
>
> I want to propose a configurable path to ~/.guix-home, and allow this to be
> chosen in the (home-environment ...) declaration.  It would expose a
> GUIX_HOME_PATH_ENVIRONMENT variable[0] so that one could dynamically retrieve
> the path to it, if needed in scripts or similar.  The implementation would 
> also
> need to be able to handle changes in the (home-environment ...) declaration,
> and know when to remove the old symlink from ~/.guix-home to the new path,
> similar to what the gnu/home/services/symlink-manager.scm does nowadays.
>
> How do you feel about this?  What do you think?  Is there a shortcoming,
> pitfalls, limitations that this approach entails?
>
> I'm willing do work on the implementation and on tests where applicable, and
> send the patches (eventually when I get this done =p).  I wanted to raise a
> discussion before jumping into the code, even to get input and see how the
> community feels about this.
>
> WDYT?

Hi EuAndreh,

This feature was removed from Guix Home 10 months ago:
https://git.sr.ht/~abcdw/rde/commit/a4b3a93b88f29eb4b37695e04e0ca200184fec28

I don't remember all the reasons, but it was slightly problematic.  I'll
name a few things, which come to my mind:

- Due to implementation of guix services extension mechanism, it's
  necessary to pass the path to guix home directory to some services
  explicitly and instantiate them even if they not used.

https://git.sr.ht/~abcdw/rde/commit/a4b3a93b88f29eb4b37695e04e0ca200184fec28#gnu/home.scm-1-4

- It's hard to cleanup environment variables like PATH and similiar when
  GUIX_HOME_DIRECTORY changed.
  
- It was hard to know if and where the previous generation was
  installed, right now it can be easier, but some edge cases can pop up.
  For example if activation script called outside of `guix home
  reconfigure` or some other circumstances.

If I remember something else, I'll let you know.

I don't dissuade you, but not sure if abilitiy to move ~/.guix-home
around worth the hassle.  Aesthetically pleasant paths in the cost of
development and maintaining a feature, which affects and complicates
many places.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Multiple profiles with Guix Home

[Andrew Tropin]

On 2022-05-03 20:34, Liliana Marie Prikler wrote:

> Am Dienstag, dem 03.05.2022 um 17:13 +0300 schrieb Andrew Tropin:
>> On 2021-10-03 12:50, Liliana Marie Prikler wrote:
>> 
>> > Hi Guix,
>> > 
>> > it's been a while since the discussion of whether or not to collect
>> > multiple profiles into a single directory [1].  This suggestion
>> > takes inspiration from that, but goes a vastly different route. 
>> > Instead of using environment variables to control Guix, it takes
>> > advantage of the recently added Guix Home, even if it is still a
>> > technical preview.
>> > 
>> > So, what's the proposition?  I suggest we modify home-profile-
>> > service-type (or add a new service) such that it takes a list of
>> >  records instead of a list of packages.  This record
>> > would be defined as
>> > 
>> >   (define-record-type*  home-profile
>> >     make-home-profile home-profile? this-home-profile
>> >     (location home-profile-location) ; string, e.g. $HOME/.guix-
>> > profile
>> >     (short-name home-profile-short-name) ; string or #f, if given
>> >  ; construct a symlink in
>> >  ; /var/guix/.../per-user/
>> >     (manifest %home-profile-manifest) ;  or #f
>> >     (packages home-profile-packages) ; list of  or #f
>> >  ; fallback for manifest
>> >     (enabled? home-profile-enabled?) ; boolean, default #t
>> >     [...])
>> > 
>> >   (define (home-profile-manifest home-profile)
>> >     (or (%home-profile-manifest home-profile)
>> >     (and=> (home-profile-packages home-profile) 
>> >    packages->manifest
>> > 
>> > On init/reconfigure, `guix home' creates/updates all home-profiles
>> > which have a home-profile-manifest that is not #f and links them to
>> > the appropriate locations.  It also creates a shell startup script
>> > that loads those profiles that are enabled?, even if they have no
>> > manifest (this can be used to e.g. declare a pull profile, which
>> > `guix home' can't manage).  
>> > 
>> > Some existing home services would need to be adapted towards this
>> > multiple profile usage.  For instance, home-fontconfig-service-type
>> > would need to accept a list of directories, rather than hardcode
>> > its value.
>> > 
>> > What do y'all think?
>> > 
>> > <
>> > https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00358.html
>> > >
>> > 
>> > 
>> 
>> It seems doable, but not sure about costs and benifits.
> Glad I have your attention now :)
>
> Depending on your use the time spent building `guix home' could go up
> or down.  If you simply add more profiles to it, that'll be an increase
> in cost, same if you don't make use of the feature at all due to the
> time spent field sanitizing.  If you do split your home in multiple
> profiles however, you will benefit from faster union builds, which
> themselves have quadratic complexity as a lower bound.
>

Yep, I already face some relatively long builds of profiles, I don't
remember when I started to face it, but splitting into a few independent
profile can make the situation better, need to experiment with it.

>> Also, cross-profile package installation can be error-prone, for
>> example if user install an emacs in main profile and emacs packages
>> in emacsy profile we will end up in a situation, where those emacs
>> package aren't available in Emacs.  Probably some other issues will
>> become clearer during implementation.
> The solution to that would be evaluating the search paths over all
> enabled packages.

It won't work if we have "managed outside" profiles and overall seems
quite fragile.

> However, I do think it's fine to do as we did before
> for now; people are already used to this aspect of Guix, but the fact
> that they need to code up their own shell wrappers to manage multiple
> profiles is not good optics imo.

Sounds reasonable.

>> Another idea I have in mind is to make such profiles (including guix
>> home's main profile) detached from ~/.config/guix/current.  For
>> example by providing channels specification as a part of > profile>.  It will make it possible to freeze a costly-to-rebuild
>> profile at a given channels revisions and not to rebuild it, when the
>> main profile and channels for it get updated.
> I don't think that's meaningful.  For one, time-mach

Re: Multiple profiles with Guix Home

[Andrew Tropin]

On 2021-10-03 12:50, Liliana Marie Prikler wrote:

> Hi Guix,
>
> it's been a while since the discussion of whether or not to collect
> multiple profiles into a single directory [1].  This suggestion takes
> inspiration from that, but goes a vastly different route.  Instead of
> using environment variables to control Guix, it takes advantage of the
> recently added Guix Home, even if it is still a technical preview.
>
> So, what's the proposition?  I suggest we modify home-profile-service-
> type (or add a new service) such that it takes a list of  
> records instead of a list of packages.  This record would be defined as
>
>   (define-record-type*  home-profile
> make-home-profile home-profile? this-home-profile
> (location home-profile-location) ; string, e.g. $HOME/.guix-profile
> (short-name home-profile-short-name) ; string or #f, if given
>  ; construct a symlink in
>  ; /var/guix/.../per-user/
> (manifest %home-profile-manifest) ;  or #f
> (packages home-profile-packages) ; list of  or #f
>  ; fallback for manifest
> (enabled? home-profile-enabled?) ; boolean, default #t
> [...])
>
>   (define (home-profile-manifest home-profile)
> (or (%home-profile-manifest home-profile)
> (and=> (home-profile-packages home-profile) 
>packages->manifest
>
> On init/reconfigure, `guix home' creates/updates all home-profiles
> which have a home-profile-manifest that is not #f and links them to the
> appropriate locations.  It also creates a shell startup script that
> loads those profiles that are enabled?, even if they have no manifest
> (this can be used to e.g. declare a pull profile, which `guix home'
> can't manage).  
>
> Some existing home services would need to be adapted towards this
> multiple profile usage.  For instance, home-fontconfig-service-type
> would need to accept a list of directories, rather than hardcode its
> value.
>
> What do y'all think?
>
> <https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00358.html>
>
>

It seems doable, but not sure about costs and benifits.

Also, cross-profile package installation can be error-prone, for example
if user install an emacs in main profile and emacs packages in emacsy
profile we will end up in a situation, where those emacs package aren't
available in Emacs.  Probably some other issues will become clearer
during implementation.

Another idea I have in mind is to make such profiles (including guix
home's main profile) detached from ~/.config/guix/current.  For example
by providing channels specification as a part of .  It
will make it possible to freeze a costly-to-rebuild profile at a given
channels revisions and not to rebuild it, when the main profile and
channels for it get updated.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

XDG_CONFIG_DIR and dotfiles handling in Guix Home

[Andrew Tropin]

In https://issues.guix.gnu.org/52808 we introduced a new service type
called home-xdg-configuration-files-service-type, its purpose should be
clear from the name: It used to define configuration files, which will
go to XDG_CONFIG_HOME (default value is ~/.config) during activation of
new home-environment.

Here an example value, which can be used to extend this service type:

--8<---cut here---start->8---
`(("sway/config" ,(function-producing-file-like-object ...))
  ("tmux/tmux.conf" ,(function-producing-file-like-object ...)))
--8<---cut here---end--->8---

Previously, the task of managing xdg configuration files was carried by
home-files-service-type, but there is a special handling for config/
subdirectory, which can be unexpected.  To make it clear that
xdg configuration files goes to XDG_CONFIG_HOME we created a separate
service type.

If you have any hand-made personal home services, please migrate them to
home-xdg-configuration-files-service-type.  Also, don't hesitate to
contribute home services to Guix! :)

Another downside of home-files-service-type is that for historical
reasons it requires to use a path without leading dot and adds it
automatically during activation, which makes it impossible to create a
directory or file without leading dot with it, for example ~/wow.  This
behavior is non-intuitive, so in two weeks we will make a breaking
change to fix it.

It won't affect home services, which use
home-xdg-configuration-files-service-type, so please migrate to it from
home-files-service-type before this fix or keep this date (April 8) in
mind and update your services, when the fix is out.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Return back original implementation for text-config serialization

[Andrew Tropin]

On 2022-02-05 12:09, Ludovic Courtès wrote:

> Hi!
>
> Maxim Cournoyer  skribis:
>
>> Pardon my ignorance about Guix Home, but couldn't we have configuration
>> as records by default, and the lower level, config stitching primitives
>> still available to hand craft strings that could be used as the value of
>> an 'extra-config' field, for example?
>>
>> It seems to me the use of records for configurations in Guix Home would
>> be the natural choice, as Guix System users are already familiar with
>> them and it leans to better discoverability/documentation.
>
> Guix Home uses records for configuration and the same service as Guix
> System, and I think it’s important that it remain this way for the
> reasons you give and also from a maintenance viewpoint.
>
> Ludo’.

I think I agree on that, probably home services and system services in
Guix proper should follow the same style.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Return back original implementation for text-config serialization

[Andrew Tropin]

On 2022-02-05 12:34, Maxime Devos wrote:

> Andrew Tropin schreef op wo 26-01-2022 om 11:36 [+0300]:
>> In addition to the problems I mentioned above:
>> 
>> 1. Mixed usage of two configuration languages (nginx-conf and lisp).
>> 2. Having a string, which should be properly escaped (luckily for
>> this
>> example it's not a problem).
>
> Mixing two configuration languages can be avoided by supporting
> everything with records.
>

I suppose it will lead to a huge maintenance burden, but it's just a
guess.

>> 
>> we also:
>> 
>> 3. Have to implement our own templating engine (using format function
>> in this case) to share the values from guile with the config.
>
> This seems to be the same for this list based configuration system
> and record based configuraiton system; for the nginx example you gave,
> all these lists with parentheses need to turned into something with
> brackets that nginx understands anyway.
>
>> 4.1. Don't know where extra-content goes. (It goes to http section
>> not the
>> end of the file, so we have to start with "}" to get a correct
>> configuration).
>
> Can be solved by adding missing options to the Guix service definition
> (and documentation) when the need arises.
>
>> 4.2. Don't control where it must be placed. (Can be important in
>> other
>> use cases, which I can share if needed).
>
> Likewise.
>
>> 5. Have inconsistent implementation of extra-config, extra-content,
>> raw-lines
>> and other escape hatches (We need to learn it everytime we write a
>> new
>> service configuration).
>
> Likewise.
>
> Also, the mapping of upstream configuration files to lists in Guix
> seems far from obvious to me: in https://issues.guix.gnu.org/52698,
> how am I supposed to know that 'us,ru' must be a symbol, why isn't
> it a string?

It's quite obvious.  ((layout us,ru)) will be translated to
`layout us,ru` and this is what expected by man 5 sway-input.

Strings and their purpose are covered below.

> If one of the strings for some property includes a special character
> from the configuration language (say, '$'), should it be escaped in
> Guix ((bindsym ... "[class=\"$100 dollars\"]" ...) or (bindsym
> ... "[class=\"\\$100 dollars\""]""))?

Not sure about this question.  If this character have to be escaped in
the target configuration, "[class=\"\\$100 dollars\"]" will produce what
you need: [class="\$100 dollars"].

According to string serialization: In first iteration I made a soft
escape hatch (all strings are serialized to its values), it made it
possible to express this CRITERIA (man 5 sway) statement you menshioned
above.

I added a proper gexp support a little later, but the example with
string already was in use.  Currently it should be done this way:

`((bindsym ... ,#~"[class=\"$100 dollars\"]" ...))

And probably strings must be serialized to quoted values now, if I
make home-sway v2 it will be done this way.

I didn't make a CRITERIA to be a part of a grammar because:

1. I needed a working prototype fast to move forward on Guix Home
itself.
2. I encountered a bug in guile compiler and already spend a lot of time
on home-sway service, after I finally localized it and it was fixed by
Andy.  I decided to postpone further improvements of sway service for
later times.

> Why (bindsym ... "[class=\"foo\"]") instead of
> (bindsym ... (= class "foo"))?

This one is good.  As you see I didn't made a CRITERIA a part of the
grammar, so there is no proper way to express it without escape hatch,
however home-sway v2 can be done slightly different, more on that in the
reply to lists and vectors question.

>
> Why (bindsym ... exec emacsclient ...) and not
> (bindsym ... exec (file-append emacs "/bin/emacsclient) ...)?
> How am I supposed to know whether emacs is in the path or not,
> and if it is, is this merely an implementation detail?

In most cases it should be
`((bindsym ... exec ,(file-append emacs "/bin/emacsclient") ...))

You are right.

>
> How would  I know if it's (bindsym ... exec emacsclient -c --eval
> "'(eshell)'") or (bindsym ... "exec emacsclient -c --eval
> \"'(eshell)'\"")?  Since the idea is to keep as close to the
> configuration language as possible, shouldn't it be the second?

exec is a part of configuration grammar and it should not be quoted.
Command itself doesn't have to be quoted too, but probably can be if you
want:

`((bindsym ... exec ,#~"'emacsclient -c --eval \"\\'(eshell)\\'\"'"))

>
> Why lists and not vectors?

This one is good as well, back in the day I was implment

Re: Return back original implementation for text-config serialization

[Andrew Tropin]

On 2022-01-27 00:04, Maxim Cournoyer wrote:

> Hi Andrew,
>
> Andrew Tropin  writes:
>
> [...]
>
>> Ludovic mentioned someday that nginx-configuration is problematic, but I
>> highlighted the generic problems, which are applicable for many other
>> guix service configurations.
>>
>> I discussed some other pros and cons of record-based configurations in
>> https://issues.guix.gnu.org/52698
>>
>> and I see the benifits of the records, but I'm not sure if they
>> outweight the weaknesses.
>>
>> It maybe sound unrelated to this thread, but it's actually very ontopic,
>> because it lead to the design and implementation of home services
>> configuration approach in general and slurp-file-gexp and text-config in
>> particular.
>
> Pardon my ignorance about Guix Home, but couldn't we have configuration
> as records by default, and the lower level, config stitching primitives
> still available to hand craft strings that could be used as the value of
> an 'extra-config' field, for example?

extra-config/extra-content/file doesn't play well with the rest of
configuration record.

See the proposed patch, which introduces home service for redshift:
https://issues.guix.gnu.org/53466

I briefly mentioned it, but can elaborate if necessary.

To be clear the top-level SOMETHING-configuration still being the
record, fields, which introduces some complex changes like
shepherd-service? or something-else-quite-big still fields of this
record, but what get serialized to config file will be mostly a plain
datastructure in the approach I propose and recommend.

> It seems to me the use of records for configurations in Guix Home would
> be the natural choice, as Guix System users are already familiar with
> them and it leans to better discoverability/documentation.

The point about Guix System users is valid, however I don't see it as a
big paradigm shift or very different approach.

I made a few points about discoverability/documentation in issue about
redshift.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Return back original implementation for text-config serialization

[Andrew Tropin]

> I have some attention problems, so I don't follow all the patches on
> guix-patches, please CC me for Guix Home related changes if it's
> possible and not very burdening.  

I'll make a special search query, which shows all the messages with
"home:" in subject line, so I should be fine on following Guix Home
related threads, still don't hesitate to CC me =)

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Return back original implementation for text-config serialization

[Andrew Tropin]

On 2022-01-24 16:37, Ludovic Courtès wrote:

> Hi Andrew,
>
> Andrew Tropin  skribis:
>
>>> Making Guix Home part of Guix was and still is a commitment, in
>>> particular the commitment that we’d all be working on one
>>> implementation, that there are no “competitive incompatible
>>> implementations”.  It’s a choice we made, not a phenomenon we’re
>>> passively observing.
>>
>> This is exactly what I want to achieve: To be able to collectively work
>> on one consistent implementation, but fee0bc, which slipped to the
>> master unreviewed, splitted home service configuration approach into two
>> competitive implementations, a few essential home services in guix repo
>> and bigger rest of non-essential stuck in rde.
>
> I love that rde is going much further than Guix, but I think it’s in
> nobody’s interest to “compete”.
>
> The change in question was discussed at length and reviewed at
> <https://issues.guix.gnu.org/50967>.
>

The intent of the patch series was to rename modules and the change
about text-config was added somewhere in between.  I asked to move it
out to the separate thread and do a separate review on that, but seems
the message was missed.

> I think this patch requires more discussion and better to keep it
> outside of this patch series.  Skimmed throught other patches, overall
> LGTM.

The proper review of this big patch series with a few unrelated changes
is hard and inefficient.  We can see that here:
https://issues.guix.gnu.org/50967#66

The semantically-incorrect change was applied, not mentioning that the
discussion about this whole patch #13 wasn't finished in my opinion.

I'll be more clear next time and will state the intent more precisely to
prevent such situations in the future.


Sorry for rising the same thread again and again, but it's really
improtant in my opinion and I would like to complete this discussion.

Seems Maxime rised good questions and proposed nice ideas and discussion
is going forward.

>> I already mentioned at least two possible ways to handle this
>> situtation:
>> 1. Rewrite the rest of rde home services.
>> 2. Rollback this change.
>>
>> I'm ok with both options, but #1 requires much more human hours to
>> complete and I still not sure if fee0bc was introduced for strong
>> reasons or was added almost accidentially.  So I try to find a
>> justification for this change.
>
> I don’t want to cause troubles in rde for you and its users, but I also
> don’t want Home decisions to be discussed there.
>
>>> Are there Guix Home issues reporting this?
>>>
>>
>> Just a 3 cases I observed in Guix Russia telegram chat.
>
> OK.  I don’t see anything at <https://issues.guix.gnu.org> though, which
> is where I’d expect bug reports for Guix Home.
>

Of course, I try to redirect people to guix mailing lists, but despite
this fact the discussions and question happens in other places too.

>>> Are there any new arguments since the already lengthy discussions that
>>> led to fee0bced7fec2f9950957976a28f033edd4f877c?  Is it really what’s
>>> leading to Guix Home being stale, or is there something else?
>>
>> IMO, changes to text-config in fee0bc really makes it harder to continue
>> the work on many Guix Home related tasks.
>
> It feels exaggerated to me, but that’s perhaps because I’m overlooking
> important aspects.
>
> I’d like us to move forward on this.  I think the best course of action
> is to focus on concrete things rather than abstract design discussions.
>
> Can we move, one by one, a few more services from rde to Home?
>
> Earlier I mentioned the SSH client service, but there are more.  When we
> move them, let’s see if problems arise related to this pattern or to
> other changes made in Guix Home.  At that point perhaps it’ll be clearer
> for everyone (or at least for me) what concrete problems this poses and
> how we could address it.
>
> How does that sound?
>

Ok, let's try, but please don't hurry, a few first services are
important, because they set the style and I would really want it to be
consistent and well-designed.

> In the meantime I submitted a patch for my first Home service this
> week-end.  :-)

Saw one of your week-end patches, will find the rest, test them and
share my thoughts in a few days.

I have some attention problems, so I don't follow all the patches on
guix-patches, please CC me for Guix Home related changes if it's
possible and not very burdening.  

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Return back original implementation for text-config serialization

[Andrew Tropin]

On 2022-01-21 10:30, Maxime Devos wrote:

> Andrew Tropin schreef op do 20-01-2022 om 16:20 [+0300]:
>> [...]
>> 
>> From what I understood from Liliana's and Maxime's replies: I'm not the
>> only one finding the original implementation to be more intuitive and
>> consistent with the rest of Guix API.  Please, correct me if I'm wrong.
>
> To be clear:
>
>   * >> source \
> >> /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh
>
> How about defining a procedure
>
> (define (source-file file-like)
>   (mixed-text-file "source " file-like)),

Possible, but not really necessary I think it will be ok to just use:

(mixed-text-file "" "source " file-like)

It looks like a light missuse of file like objects because we have to
specify "" file name each time, nothing critical, but still feels a
little wierd.

>
> the 'concatenated-file' described below, and giving an example or
> two in the manual on how to use it?
>
> (concatenated-file ""
>   (source-file (local-file "some-bash-functions.sh"))
>   (mixed-text-file "" (file-append coreutils "/bin/echo")
>   "hello Guix Home!) "\n"
>"invoke-some-function" "argument")) 

concatenated-file is not needed, we already can use source-file and
mixed-text-file directly in bash-home-configuration:
(bashrc
 (list
  (source-file (local-file "some-bash-functions.sh"))
  (mixed-text-file "" (file-append coreutils "/bin/echo")
   " hello Guix Home!) \n"
   "invoke-some-function" "argument"))
   
>
> * I don't like 'slurp-file-gexp' (what are G-exps doing there, and
> what's slurping?).  A better name would improve things though.

The G-expression, which slurps the file.  It's just a funny name I
borrowed from Clojure:
https://clojuredocs.org/clojure.core/slurp
It was just WIP name, I don't mind naming it differently.

> Also, we already have 'mixed-text-file', so maybe we can create
> an ‘concatenated-file'?

Yes, I was missing it a few times, when I started to use guix services a
year ago.

Current implementation of text-config do a similar thing, but it would
be cool to have a separate helper function independent from guix
services.

>
> (appended-file name (plain-file "" "foo") (local-file "bar"))
> -->
> foo
> 
>
> A slight downside is that the plain-file needs to be given a name,
> in this case "", as you have noted for 'mixed-text-file', but that
> can be avoided to a degree by giving it "" as name.

Not a big deal I think.  Optionally, we can support strings, so it will
work as a mixed-text-file, but will be inserting the content of the file
instead of the path, however it can be a little confusing.

>
> * IIUC, the reason why 'slurp-file-gexp' or the like was necessary,
> was because the implementation doesn't use records for
> configuration, but rather some mixture of S-exps and ‘copy this
> and that file is the serialisation here and there’.
>
> I would prefer not using S-exps like
>
> (home-service barfoo-service-type
>   (barfoo-configuration
> (config
>   `((this-option "that")
> (foo (bar z)
>  (foobar (include ,(local-file ...)))
>
> and instead write these 'this-option', 'foo', 'bar' and 'foobar'
> in records, such that there's to some degree a type system and
> some discoverability.

Very good you rised this question.  Discoverability is true, with
records it's a little easier to get tips from geiser, however, the
safety provided by this weak type system is almost illusory, also, the
same degree of type correctness can be achieved without records.

IIRC, I covered this tradeoff in Writing Service Configuration manual
section: https://issues.guix.gnu.org/52698

>
> Yes, if there's a lot of options that can be configured,
> then initially Guix won't support all, but it should be easy
> to patch Guix to support more options on an as-needed basis.
> There can also be an 'extra-content' escape hatch.
>
> For software that doesn't support inclusion directives in
> configuration, we could:
>
>   1. patch upstream to support it (it's free software and
>  it's potentially useful outside Guix, so why not?)
>   2. or do something like 'concatenated-file'
>
> with a preference for (1).
>
> As such, I'm not exactly agreeing, since there appear to be better
> options than 'slurp-file-gexp'.  Renaming

Re: Return back original implementation for text-config serialization

[Andrew Tropin]

On 2022-01-21 10:30, Maxime Devos wrote:

> Andrew Tropin schreef op do 20-01-2022 om 16:20 [+0300]:
>> [...]
>> 
>> From what I understood from Liliana's and Maxime's replies: I'm not the
>> only one finding the original implementation to be more intuitive and
>> consistent with the rest of Guix API.  Please, correct me if I'm wrong.
>
> To be clear:
>
>   * >> source \
> >> /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh
>
> How about defining a procedure
>
> (define (source-file file-like)
>   (mixed-text-file "source " file-like)),

Possible, but not really necessary I think it will be ok to just use:

(mixed-text-file "" "source " file-like)

It looks like a light missuse of file like objects because we have to
specify "" file name each time, nothing critical, but still feels a
little wierd.

>
> the 'concatenated-file' described below, and giving an example or
> two in the manual on how to use it?
>
> (concatenated-file ""
>   (source-file (local-file "some-bash-functions.sh"))
>   (mixed-text-file "" (file-append coreutils "/bin/echo")
>   "hello Guix Home!) "\n"
>"invoke-some-function" "argument")) 

concatenated-file is not needed, we already can use source-file and
mixed-text-file directly in bash-home-configuration:
(bashrc
 (list
  (source-file (local-file "some-bash-functions.sh"))
  (mixed-text-file "" (file-append coreutils "/bin/echo")
   " hello Guix Home!) \n"
   "invoke-some-function" "argument"))
   
>
> * I don't like 'slurp-file-gexp' (what are G-exps doing there, and
> what's slurping?).  A better name would improve things though.

The G-expression, which slurps the file.  It's just a funny name I
borrowed from Clojure:
https://clojuredocs.org/clojure.core/slurp
It was just WIP name, I don't mind naming it differently.

> Also, we already have 'mixed-text-file', so maybe we can create
> an ‘concatenated-file'?

Yes, I was missing it a few times, when I started to use guix services a
year ago.

Current implementation of text-config do a similar thing, but it would
be cool to have a separate helper function independent from guix
services.

>
> (appended-file name (plain-file "" "foo") (local-file "bar"))
> -->
> foo
> 
>
> A slight downside is that the plain-file needs to be given a name,
> in this case "", as you have noted for 'mixed-text-file', but that
> can be avoided to a degree by giving it "" as name.

Not a big deal I think.  Optionally, we can support strings, so it will
work as a mixed-text-file, but will be inserting the content of the file
instead of the path, however it can be a little confusing.

>
> * IIUC, the reason why 'slurp-file-gexp' or the like was necessary,
> was because the implementation doesn't use records for
> configuration, but rather some mixture of S-exps and ‘copy this
> and that file is the serialisation here and there’.
>
> I would prefer not using S-exps like
>
> (home-service barfoo-service-type
>   (barfoo-configuration
> (config
>   `((this-option "that")
> (foo (bar z)
>  (foobar (include ,(local-file ...)))
>
> and instead write these 'this-option', 'foo', 'bar' and 'foobar'
> in records, such that there's to some degree a type system and
> some discoverability.

Very good you rised this question.  Discoverability is true, with
records it's a little easier to get tips from geiser, however, the
safety provided by this weak type system is almost illusory, also, the
same degree of type correctness can be achieved without records.

IIRC, I covered this tradeoff in Writing Service Configuration manual
section: https://issues.guix.gnu.org/52698

>
> Yes, if there's a lot of options that can be configured,
> then initially Guix won't support all, but it should be easy
> to patch Guix to support more options on an as-needed basis.
> There can also be an 'extra-content' escape hatch.
>
> For software that doesn't support inclusion directives in
> configuration, we could:
>
>   1. patch upstream to support it (it's free software and
>  it's potentially useful outside Guix, so why not?)
>   2. or do something like 'concatenated-file'
>
> with a preference for (1).
>
> As such, I'm not exactly agreeing, since there appear to be better
> options than 'slurp-file-gexp'.  Renaming

Re: Return back original implementation for text-config serialization

[Andrew Tropin]

On 2022-01-18 15:26, Ludovic Courtès wrote:

> Hi,
>
> Andrew Tropin  skribis:
>
>> During the upstreaming process of Guix Home commit
>> fee0bced7fec2f9950957976a28f033edd4f877c slipped into master.  It
>> introduces a different serialization approach for text-config from what
>> was orginally used:
>> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuration.scm?h=2c451db39aabc69bdbf186f412ee6e0b4e180ccb#n386
>>
>> This new approach is inconisistent with the ideas used in the number of
>> other home services (not only the ones using text-config):
>> https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/item/gnu/home-services
>>
>> So I had to fork it back to avoid an inconsistency and renamed
>> text-config to gexp-text-config to avoid a confusion with upstreamed
>> version.
>> https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/item/gnu/home-services-utils.scm#L355
>>
>> Having two serialization approaches stops me from upstreaming the rest
>> of home services from rde to Guix and also makes a split to rde home
>> services and guix home services, which I would like to avoid.
>
> I’d like to clarify how I think we should work.  Guix development
> happens here, on Guix channels, using the project’s peer review
> processes.
>
> What rde does certainly is inspirational, and that’s what got us Home in
> the first place; in my view, we may sometimes choose to take ideas from
> rde in Guix and Guix Home, but rde development alone cannot be used to
> justify changes.
>

Hi Ludovic,

It's not a justification for the changes it's a recap of the past events
to provide the context.  We were working on moving Guix Home and home
services from rde to guix, but in the middle of this process the change
to text-config type happend and now it's not possible to continue
upstreaming without rewriting the rest of home services in rde repo or
reverting back this change.

>
>> We need to decide, which approach should be used or we will end up with
>> two competitive incompatible implementations and unecessary split of
>> effort and lose of human force and time.
>
> Making Guix Home part of Guix was and still is a commitment, in
> particular the commitment that we’d all be working on one
> implementation, that there are no “competitive incompatible
> implementations”.  It’s a choice we made, not a phenomenon we’re
> passively observing.

This is exactly what I want to achieve: To be able to collectively work
on one consistent implementation, but fee0bc, which slipped to the
master unreviewed, splitted home service configuration approach into two
competitive implementations, a few essential home services in guix repo
and bigger rest of non-essential stuck in rde.

I already mentioned at least two possible ways to handle this
situtation:
1. Rewrite the rest of rde home services.
2. Rollback this change.

I'm ok with both options, but #1 requires much more human hours to
complete and I still not sure if fee0bc was introduced for strong
reasons or was added almost accidentially.  So I try to find a
justification for this change.

From what I understood from Liliana's and Maxime's replies: I'm not the
only one finding the original implementation to be more intuitive and
consistent with the rest of Guix API.  Please, correct me if I'm wrong.

>> The new text-config serialization implementation (after fee0bc commit)
>> doesn't support gexps and tries to insert the literal content of the
>> file in place where file-like object was used, which
>>
>> 1. Confuses the users.
>> People reporting that it's hard to implement something like
>>
>> source \
>> /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh
>>
>> with the new approach (using file-like objects), and they switch to the
>> original implementation of home services for shells (the ones currently
>> living in rde repo), which allows to use gexps.
>
> Are there Guix Home issues reporting this?
>

Just a 3 cases I observed in Guix Russia telegram chat.

>> 2. Looks strange implementation-wise.
>>
>> If we want to insert the file path to file-like object for new-style
>> text-config internally we do something like
>>
>> (mixed-text-file ...
>>  "source \" "\n"
>>  #~(read-everything-from-file
>> #$(computed-file "unecessary-file-name"
>>#~#$(local-file "blabla.sh"
>
> When would one write such a thing?

I have very same question :)

It's what happens internally in current implementation, something like
that goes to home-files-service-type.

>
> A couple of examples from Guix System:  has an
> ‘include’ field take accept

Re: Return back original implementation for text-config serialization

[Andrew Tropin]

On 2022-01-10 21:12, Liliana Marie Prikler wrote:

> Am Montag, dem 10.01.2022 um 12:49 +0300 schrieb Andrew Tropin:
>> [T]he whole point of escape hatch is to make it possible to reuse
>> existing files directly without any manipulation on them and importer
>> should demonstrate how to do it.
> That'd make more sense if the importer copied bashrc to some well-known
> location (e.g. ~/.config/guix/data/.bashrc) and then used that rather
> than the file it wishes to replace.  IIRC that was one suggested
> behaviour of Guix Home in the past, but it didn't get approval because
> users wouldn't typically ask for that copying to happen.  If you make
> it so that plain-file is used normally, but add a switch to express
> things in terms of local-file instead, that'd work.  
>
> OTOH, I do think local-file is already well-documented on its own, so
> perhaps it'd only take a cookbook entry to show it in combination with
> Guix Home and an explanation as to why Guix Home doesn't do that
> normally while explaining all the caveats.

It seems that current implementation of importer copy files to the
directory provided as command line argument and after that generates a
config file, which refers those files with local-file.

Overall, I think that the importer is not really well-defined both in
terms of purpose and implementation and maybe it will be better to hold
it until it polished.

>> If importer internally do some manipulation (escaping) with the
>> content of the file and places the result in the string in scheme
>> file, user won't be able to replicate such process easily for other
>> services, which not covered by the importer. If I understood
>> correctly what you meant in the first message.
> Yes, the user would have to manually quote every new line of code
> they're adding, but they're free to use all other file-like objects,
> including local-file.  Having (bashrc (local-file ".bashrc")), whether
> implemented on top of slurp-file-gexp or not, is inherently dangerous,
> though.
>

From this

>> > The point I'm making is that we shouldn't swap out one bad
>> > abstraction for another, but pave the road towards good
>> > abstractions, e.g. G-expressions in the way the rest of Guix
>> > typically uses them.
>> 
>> Actually, for me, the original implementation looks consistent with
>> how the rest of Guix treats G-expressions (uses already known
>> abstraction) and only new one intoduces a new abstraction.
> That's the point.  The old style works just like you'd expect it to, it
> becomes a problem when you try to feed it stuff like slurp-file-gexp to
> work around some limitations in a way I'm not convinced makes sense.
>

and this, it looks like you are concerned with local-file, which can
lead to the non-reproducible code, when for example the local-file
refers something outside of the git repo and on another machine the same
config will lead to an error?  And slurp-file-gexp additionally hides it
from the user by wrapping local-file.  Correct me if I'm wrong.

>> [I]t's already possible to achieve the same [-- merging multiple
>> bashrc snippets into a single file --] with gexps/file-like in both
>> new and old text-config implementations.
> I find the lack of services in your example concerning, but I'll take
> your word for it.  In that case, using a gexp for bashrc in the typical
> sense is probably the best idea, but we still need to do something with
> the reliance on slurp-file-gexp.
>
> Cheers
>
>> 
> PS:
>> It's offtopic, but when you will have time please take a look at
>> https://issues.guix.gnu.org/52388.
> Hahaha, it's been a month, hasn't it?  There's some aesthetic
> unpleasanties, so I'm not sure if I'll upstream it with slight
> stylistic changes or give you some harsher feedback, but I'll try to
> decide this weekend.
>

Yep :)  Thank you, will be waiting for it!)

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Return back original implementation for text-config serialization

[Andrew Tropin]

On 2022-01-09 20:44, Liliana Marie Prikler wrote:

> Hi,
>
> Am Sonntag, dem 09.01.2022 um 20:48 +0300 schrieb Andrew Tropin:
>> On 2022-01-09 12:19, Liliana Marie Prikler wrote:
>> 
>> > Hi Andrew,
>> > 
>> > Am Sonntag, dem 09.01.2022 um 12:12 +0300 schrieb Andrew Tropin:
>> > 
>> > > Before fee0bc serialization for text-config worked this way:
>> > > --8<---cut here---start->8---
>> > > `("string here"
>> > >   ,#~"string valued gexp"
>> > >   "source \"
>> > >   ,(local-file "blabla.sh"))
>> > > --8<---cut here---end--->8---
>> > > 
>> > > would yield something like:
>> > > 
>> > > --8<---cut here---start->8---
>> > > string here
>> > > string valued gexp
>> > > source \
>> > > /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh
>> > > --8<---cut here---end--->8---
>> > > 
>> > > [...]
>> > > 
>> > > The new text-config serialization implementation (after fee0bc
>> > > commit) doesn't support gexps and tries to insert the literal
>> > > content
>> > > of the file in place where file-like object was used[.]
>> > I agree that the old one looks nicer in this context, but wasn't
>> > the new one introduced to solve the issue of (slurp-file-gexp) in
>> > the importer?  Meaning whichever way we go, we need something that
>> > allows us to insert literal file contents of another file at more
>> > or less G- exp compile time.
>> > 
>> 
>> From my experience the usage of slurp-file-gexp is somewhat really
>> rare, so I didn't upstream it originally, keeping in mind that it is
>> possible to use the gexp mentioned below directly and that later we
>> can add slurp-file-gexp or alternative if necessary.  Just missed
>> that importer already uses it.
>> 
>> We could just do something like that instead of slurp-file-gexp:
>> --8<---cut here---start->8---
>> #~(call-with-input-file #$(local-file "./files/bashrc")
>>     (@ (ice-9 textual-ports) get-string-all))
>> --8<---cut here---end--->8---
>> 
>> Or just take the implementation
>> https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/gnu/home-services-utils.scm#L90
>> and rename it to read-file-content-gexp or somewhat more apropriate
>> and use it.
> Using ill-defined slurp-patterns at all just adds ways of shooting
> yourself in the foot.  You're turning Guix into an ouroboros that reads
> itself inside-out.  Better restrict such patterns to where they cause
> the least harm and make their effects very explicit.

Not sure what you mean.

>> > Perhaps that issue could be solved, if instead the importer just
>> > reads the file contents and declares it as a variable as in (define
>> > %bashrc " ;; Original contents of bashrc ") (define bashrc (plain-
>> > file %bashrc)).
>> > 
>> > WDYT?
>> 
>> Another possible solution, but I would prefer to stick with the
>> direct usage of gexp with the code for reading a file, because
>> importer is intended for creation of an example configuration and
>> user will need to continue the work on it and copying the content of
>> bashrc and other configs to scheme files, escaping string can be a
>> little tedious.
> There is certainly a tradeoff here, but I think explicitly showing
> (plain-file CONTENT) is the right approach here.  Users are going to
> figure out mixed-text-file exists soon enough.  As for proper string
> escaping, that's not really an excuse imo -- pretty-print exists and
> you can use it. 

Yep, of course it possible, but I mean that the whole point of escape
hatch is to make it possible to reuse existing files directly whithout
any manipulation on them and importer should demonstrate how to do it.
If importer internally do some manipulation (escaping) with the content
of the file and places the result in the string in scheme file, user
won't be able to replicate such process easily for other services, which
not covered by the importer. If I understood correctly what you meant in
the first message.

>> read-everything-from-file is just a shorthand for
>> 
>> --8<---cut here---start->8---
>> #~(begin
>>     (

Re: Return back original implementation for text-config serialization

[Andrew Tropin]

On 2022-01-09 13:19, Maxime Devos wrote:

> Andrew Tropin schreef op zo 09-01-2022 om 12:12 [+0300]:
>> [...] There is another less generalized example, which demonstrates
>> how
>> serialization of sway configuration works right now.
>> 
>> --8<---cut here---start->8---
>> `((include ,(local-file "./sway/config"))
>>   (bindsym $mod+Ctrl+Shift+a exec
>>    ,(file-append emacs "/bin/emacsclient") -c --eval
>> "'(eshell)'")
>>   (bindsym $mod+Ctrl+Shift+o "[class=\"IceCat\"]" kill)
>>   (input * ((xkb_layout us,ru)
>>     (xkb_variant dvorak,
>> --8<---cut here---end--->8---
>> 
>> would yield something like:
>> 
>> --8<---cut here---start->8---
>> include /gnu/store/408jwvh6wxxn1j85lj95fniih05gx5xj-config
>> bindsym $mod+Ctrl+Shift+a exec /gnu/store/...-emacsclient -c --eval
>> '(eshell)'
>> bindsym $mod+Ctrl+Shift+o [class="IceCat"] kill
>> input * {
>>     xkb_layout us,ru
>>     xkb_variant dvorak,
>> }
>> --8<---cut here---end--->8---
>> 
>> The new text-config serialization implementation (after fee0bc
>> commit)
>> doesn't support gexps and tries to insert the literal content of the
>> file in place where file-like object was used, which
>> 
>> 1. Confuses the users. [...]
>> 2. Looks strange implementation-wise. [...]
>> (mixed-text-file ...
>> "source \" "\n"
>> #~(read-everything-from-file
>>#$(computed-file "unecessary-file-name"
>>   #~#$(local-file "blabla.sh"
>> when originally it was
>> (mixed-text-file
>>  "source \" "\n"
>>  (local-file "blabla.sh"))
>
> Can we have (mixed-text-file "source \" "\n" (local-file "blabla.sh"))
> and the sway configuration you quoted?  That syntax seems reasonable
> and easy to use to me.  But without reintroducing slurp-file-gexp.
>
> Greetings,
> Maxime.

I think we can just rely on something like that:
--8<---cut here---start->8---
#~(call-with-input-file #$(local-file "./files/bashrc")
(@ (ice-9 textual-ports) get-string-all))
--8<---cut here---end--->8---

As I mentioned in reply to Liliana, from my experience it's a rare case,
when we really need to slurp the content of the file, in most cases
include/source and other similar consturctions can do the trick, so it
maybe not necessary to have a helper for this case at all.

WDYT?

BTW, even after reading "Code Staging in GNU Guix" paper, I still not
sure what the problem with slurp-file-gexp (except maybe name :) ).

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Return back original implementation for text-config serialization

[Andrew Tropin]

On 2022-01-09 12:19, Liliana Marie Prikler wrote:

> Hi Andrew,
>
> Am Sonntag, dem 09.01.2022 um 12:12 +0300 schrieb Andrew Tropin:
>> Before fee0bc serialization for text-config worked this way:
>> --8<---cut here---start->8---
>> `("string here"
>>   ,#~"string valued gexp"
>>   "source \"
>>   ,(local-file "blabla.sh"))
>> --8<---cut here---end--->8---
>> 
>> would yield something like:
>> 
>> --8<---cut here---start->8---
>> string here
>> string valued gexp
>> source \
>> /gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh
>> --8<---cut here---end--->8---
>> 
>> [...]
>> 
>> The new text-config serialization implementation (after fee0bc
>> commit) doesn't support gexps and tries to insert the literal content
>> of the file in place where file-like object was used[.]
> I agree that the old one looks nicer in this context, but wasn't the
> new one introduced to solve the issue of (slurp-file-gexp) in the
> importer?  Meaning whichever way we go, we need something that allows
> us to insert literal file contents of another file at more or less G-
> exp compile time.
>

From my experience the usage of slurp-file-gexp is somewhat really rare,
so I didn't upstream it originally, keeping in mind that it is possible
to use the gexp mentioned below directly and that later we can add
slurp-file-gexp or alternative if necessary.  Just missed that importer
already uses it.

We could just do something like that instead of slurp-file-gexp:
--8<---cut here---start->8---
#~(call-with-input-file #$(local-file "./files/bashrc")
(@ (ice-9 textual-ports) get-string-all))
--8<---cut here---end--->8---

Or just take the implementation
https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/gnu/home-services-utils.scm#L90
and rename it to read-file-content-gexp or somewhat more apropriate and
use it.

> 
> Perhaps that issue could be solved, if instead the importer just reads
> the file contents and declares it as a variable as in (define %bashrc
> " ;; Original contents of bashrc ") (define bashrc (plain-file
> %bashrc)).
>
> WDYT?
>

Another possible solution, but I would prefer to stick with the direct
usage of gexp with the code for reading a file, because importer is
intended for creation of an example configuration and user will need to
continue the work on it and copying the content of bashrc and other
configs to scheme files, escaping string can be a little tedious.

>> If we want to insert the file path to file-like object for new-style
>> text-config internally we do something like
>> 
>> (mixed-text-file ...
>>  "source \" "\n"
>>  #~(read-everything-from-file
>>     #$(computed-file "unecessary-file-name"
>>    #~#$(local-file "blabla.sh"
>> 
>> when originally it was
>> (mixed-text-file
>>  "source \" "\n"
>>  (local-file "blabla.sh"))
> Is unnecessary-file-name ever created in this instance?  I think we
> have something similar in other locations as well, where G-expressions
> are merged -- public keys for substitutes spring to mind.  Perhaps all
> it'd need to make use of new-style text configs is a better way of
> quoting such things, e.g. a procedure which takes a file-like object
> and produces a plain file with its name.
>
> For the record, the use of (read-everything-from-file) in your example
> -- a procedure which I'm unable to find in my local Guix checkout --
> makes it somewhat difficult to come up with concrete solutions here, so
> pardon me for being abstract.

read-everything-from-file is just a shorthand for

--8<---cut here---start->8---
#~(begin
(use-modules (ice-9 rdelim))
(with-fluids ((%default-port-encoding "UTF-8"))
  (with-input-from-file #$COMPUTED_FILE_CALL_HERE read-string)))
--8<---cut here---end--->8---

a gexp used in
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuration.scm?h=2c451db39aabc69bdbf186f412ee6e0b4e180ccb#n386

The example was already verbose, so I decided to simplify it a little
bit.

Actually, it's very similar to what slurp-file-gexp does, but it's moved
inside serializer and hidden from user.  Why not to give it to the user
and eleminate two more layers of wrapping in gexps and file-likes.

To demonstrate the idea of those additional layers, 

Return back original implementation for text-config serialization

[Andrew Tropin]

During the upstreaming process of Guix Home commit
fee0bced7fec2f9950957976a28f033edd4f877c slipped into master.  It
introduces a different serialization approach for text-config from what
was orginally used:
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuration.scm?h=2c451db39aabc69bdbf186f412ee6e0b4e180ccb#n386

This new approach is inconisistent with the ideas used in the number of
other home services (not only the ones using text-config):
https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/item/gnu/home-services

So I had to fork it back to avoid an inconsistency and renamed
text-config to gexp-text-config to avoid a confusion with upstreamed
version.
https://git.sr.ht/~abcdw/rde/tree/47f6c65c82a4f6761fa1ff5b9405b363cfda6482/item/gnu/home-services-utils.scm#L355

Having two serialization approaches stops me from upstreaming the rest
of home services from rde to Guix and also makes a split to rde home
services and guix home services, which I would like to avoid.

We need to decide, which approach should be used or we will end up with
two competitive incompatible implementations and unecessary split of
effort and lose of human force and time.

I wanted to solve this question as a part of
https://issues.guix.gnu.org/52698, but seems it doesn't get enough
attention (probably cause of the volume of information in the patch).

I'll provide a few technical details, which supports the original
appoarch.

Before fee0bc serialization for text-config worked this way:
--8<---cut here---start->8---
`("string here"
  ,#~"string valued gexp"
  "source \"
  ,(local-file "blabla.sh"))
--8<---cut here---end--->8---

would yeld something like:

--8<---cut here---start->8---
string here
string valued gexp
source \
/gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh
--8<---cut here---end--->8---


There is another less generalized example, which demonstrates how
serialization of sway configuration works right now.

--8<---cut here---start->8---
`((include ,(local-file "./sway/config"))
  (bindsym $mod+Ctrl+Shift+a exec
   ,(file-append emacs "/bin/emacsclient") -c --eval "'(eshell)'")
  (bindsym $mod+Ctrl+Shift+o "[class=\"IceCat\"]" kill)
  (input * ((xkb_layout us,ru)
(xkb_variant dvorak,
--8<---cut here---end--->8---

would yield something like:

--8<---cut here---start->8---
include /gnu/store/408jwvh6wxxn1j85lj95fniih05gx5xj-config
bindsym $mod+Ctrl+Shift+a exec /gnu/store/...-emacsclient -c --eval '(eshell)'
bindsym $mod+Ctrl+Shift+o [class="IceCat"] kill
input * {
xkb_layout us,ru
xkb_variant dvorak,
}
--8<---cut here---end--->8---

The new text-config serialization implementation (after fee0bc commit)
doesn't support gexps and tries to insert the literal content of the
file in place where file-like object was used, which

1. Confuses the users.
People reporting that it's hard to implement something like

source \
/gnu/store/00fl96dj2aak4i1vqvdqzlhbmmskc7fx-blabla.sh

with the new approach (using file-like objects), and they switch to the
original implementation of home services for shells (the ones currently
living in rde repo), which allows to use gexps.

2. Looks strange implementation-wise.

If we want to insert the file path to file-like object for new-style
text-config internally we do something like

(mixed-text-file ...
 "source \" "\n"
 #~(read-everything-from-file
#$(computed-file "unecessary-file-name"
   #~#$(local-file "blabla.sh"

when originally it was
(mixed-text-file
 "source \" "\n"
 (local-file "blabla.sh"))

3. Inconsistent with other home services.

I do not insist that one approach is superior to the other and there are
of course some pros and cons for both of them, but personally I find the
old one to be more user-friendly, simpler and cleaner.  Also, having the
new implementation stops me from upstreaming all other home services,
because almost all of them allows to use gexps inside configuration
field and resolves file-like object to the path in the store instead of
literal content.

Please, express arguments, opinions and rationales and let's decide:
Keep the new approach or return back to the original one.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

[PATCH v2] doc: Add Writing Service Configuration section.

[Andrew Tropin]

* guix.texi (Writing Service Configuration): New section.
---
 doc/guix.texi | 252 +-
 1 file changed, 248 insertions(+), 4 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 333cb4117a..29d85d3dc5 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -10363,6 +10363,7 @@ compiling modules.  It can be @code{#f}, @code{#t}, or 
@code{'detailed}.
 The other arguments are as for @code{derivation} (@pxref{Derivations}).
 @end deffn
 
+@anchor{file-like objects}
 @cindex file-like objects
 The @code{local-file}, @code{plain-file}, @code{computed-file},
 @code{program-file}, and @code{scheme-file} procedures below return
@@ -15942,6 +15943,7 @@ symlink:
 Return a service that sets the host name to @var{name}.
 @end deffn
 
+@anchor{console-font-service-type}
 @defvr {Scheme Variable} console-font-service-type
 Install the given fonts on the specified ttys (fonts are per
 virtual console on the kernel Linux).  The value of this service is a list of
@@ -33717,6 +33719,7 @@ a daemon that can execute application bundles 
(sometimes referred to as
 
 @end defvr
 
+@anchor{docker-configuration}
 @deftp {Data Type} docker-configuration
 This is the data type representing the configuration of Docker and Containerd.
 
@@ -35652,10 +35655,11 @@ them in an @code{operating-system} declaration.  But 
how do we define
 them in the first place?  And what is a service anyway?
 
 @menu
-* Service Composition:: The model for composing services.
-* Service Types and Services::  Types and services.
-* Service Reference::   API reference.
-* Shepherd Services::   A particular type of service.
+* Service Composition::The model for composing services.
+* Service Types and Services:: Types and services.
+* Writing Service Configurations:: A guideline for writing guix services.
+* Service Reference::  API reference.
+* Shepherd Services::  A particular type of service.
 @end menu
 
 @node Service Composition
@@ -35851,6 +35855,245 @@ There can be only one instance of an extensible 
service type such as
 Still here?  The next section provides a reference of the programming
 interface for services.
 
+@node Writing Service Configurations
+@subsection Writing Service Configurations
+
+Guix already contains a wide variety of system and home services, but
+sometimes users might want to add new services.  This section contains
+tips for simplifying this process, and should help to make service
+configurations and their implementations more consistent.
+
+@quotation Note
+If you find any exceptions or patterns missing in this section, please
+send a patch with additions/changes to @email{guix-devel@@gnu.org}
+mailing list or just start a discussion/ask a question.
+@end quotation
+
+@subsubheading Configuration Itself
+
+As we know from previous sections, a Guix service can accept a service
+value, usually some kind of configuration record and optionally, be
+extended with additional values by other services (@pxref{Service
+Composition}).
+
+When being extended, most services take some kind of configuration
+record or a list thereof, but in some cases a simpler value is all
+that is necessary.
+
+There are some cases, when the service accepts a list of pairs or some
+other non-record values.  For example, @code{console-font-service-type}
+(@pxref{console-font-service-type}) accepts an
+association list, and @code{etc-service-type} (@pxref{etc-service-type})
+accepts a list of lists.  Those services are kinda special, they do
+auxiliary work of setting up some part of the operating system or home
+environment, or just an intermediate helpers used by other Guix
+services.  For example @code{etc-service-type} is not that useful on its
+own, but it helps other services to create files in /etc directory, when
+it necessary.
+
+However, in most cases a Guix service is wrapping some software, which
+consists of one or more packages, and configuration file or files.
+Therefore, the value for such service is quite complicated and it's hard
+to represent it with just a list or basic data type, in such cases we
+use a record.  Each such record (@pxref{SRFI-9 Records, Scheme Records,,
+guile, GNU Guile Reference Manual}) have @samp{-configuration} suffix,
+for example, the @code{docker-service-type} should accept a record type
+named @code{docker-configuration}, which contains fields used to
+configure Docker.  Configuration records for home services should also
+have a @code{home-} prefix in their name.
+
+There is a module @code{gnu service configuration}, which contains
+helpers simplifying configuration definition process.  Take a look at
+@code{gnu services docker} module or grep for
+@code{define-configuration} to find usage examples.
+
+@c Provide some examples, tips, and rationale behind @code{gnu service
+@c configuration} module.
+
+After a configuration record has been properly named and defined let's
+discuss how to name 

Re: [RFC PATCH] doc: Add Writing Service Configuration section.

[Andrew Tropin]

On 2021-12-22 09:53, Xinglu Chen wrote:

> Am Dienstag, der 21. Dezember 2021, um 13:21 +032, schrieb Andrew Tropin 
> :
>
>> * guix.texi (Writing Service Configuration): New section.
>> ---
>> After reading the source code of different system services and implementing a
>> few of home services I decided to write down most important tips for
>> implementing guix service configurations.  I belive having such a guideline
>> can simplify the development of new services and configurations for them, as
>> well as keeping those implementations consistent, which will simplify the 
>> life
>> for users too because they won't need to learn a different configuration
>> approaches for different services.
>>
>> This section is not a final document, but a starting point for discussion and
>> further extension of the guideline.  Feel free to raise a question, point to 
>> a
>> mistake, make a suggestion or propose an idea.
>
> Thanks for working on this!  I left some comments and thoughts as I read
> through it (Warning, these is quite a lot :-)).
>
>>  doc/guix.texi | 209 +-
>>  1 file changed, 205 insertions(+), 4 deletions(-)
>>
>> diff --git a/doc/guix.texi b/doc/guix.texi
>> index 333cb4117a..a48fb0e2b7 100644
>> --- a/doc/guix.texi
>> +++ b/doc/guix.texi
>> @@ -35652,10 +35652,11 @@ them in an @code{operating-system} declaration.  
>> But how do we define
>>  them in the first place?  And what is a service anyway?
>>  
>>  @menu
>> -* Service Composition:: The model for composing services.
>> -* Service Types and Services::  Types and services.
>> -* Service Reference::   API reference.
>> -* Shepherd Services::   A particular type of service.
>> +* Service Composition::The model for composing services.
>> +* Service Types and Services:: Types and services.
>> +* Service Reference::  API reference.
>> +* Shepherd Services::  A particular type of service.
>> +* Writing Service Configurations:: A guideline for writing guix services.
>>  @end menu
>>  
>>  @node Service Composition
>> @@ -35851,6 +35852,206 @@ There can be only one instance of an extensible 
>> service type such as
>>  Still here?  The next section provides a reference of the programming
>>  interface for services.
>>  
>> +@node Writing Service Configurations
>> +@subsection Writing Service Configurations
>
> The TOC menu says that “Writing Services Configurations” comes after
> “Shepherd Services”, but this doesn’t seem to be the case here.
>

Done.

>> +There are a lot of system and home services already written, but from
>> +time to time it's necessary to write one more.
>
> I would write something like
>
>   Guix already contains a wide variety of system and home services, but
>   sometimes users might want to add new services.
>
>> +This section contains
>> +tips for simplifying this process, and should help to make service
>> +configurations and their implementations more consistent.
>> +
>> +@quotation Note
>> +If you find any exceptions or patterns missing in this section, please
>> +send a patch with additions/changes to @email{guix-devel@@gnu.org}
>> +mailing list or just start a discussion/ask a question.
>> +@end quotation
>
> I don’t think this note is really necessary; there is already a section
> on contributing to the project, see “17 Contributing”.
>

Not necessary, but I would keep it for a few months to make people more
involved in the polishing of this guide.

>> +@subsubheading Configuration Itself
>> +
>> +As we know from previous section a guix service can accept a value and
>^ missing comma
> s/section/sections/
> s/guix/Guix

Done.


>
> When you say “service”, you mean a “service type”, right?  Just “value”
> sounds a bit vague, maybe

I mean service, which is instantiated from some service type.

>
>   … a value, usually some kind of configuration
>   record (@pxref{RELEVANT NODE(s)})

changed it to service value and added this note.

>
> ?
>
>> +be extended with additional values by other services.
>
> Not all services are extendable though, to avoid ambiguity, maybe
>
>   …, and optionally, be extended with additional configurations by other
>   services (@pxref{Service Composition}).
>

Done.

>> +There are some
>> +cases, when the service accepts a list of pairs or some other values for
>
> I suggest:
>
>   When being extended, most services take some kind of configuration

[RFC PATCH] doc: Add Writing Service Configuration section.

[Andrew Tropin]

* guix.texi (Writing Service Configuration): New section.
---
After reading the source code of different system services and implementing a
few of home services I decided to write down most important tips for
implementing guix service configurations.  I belive having such a guideline
can simplify the development of new services and configurations for them, as
well as keeping those implementations consistent, which will simplify the life
for users too because they won't need to learn a different configuration
approaches for different services.

This section is not a final document, but a starting point for discussion and
further extension of the guideline.  Feel free to raise a question, point to a
mistake, make a suggestion or propose an idea.

Best regards,
Andrew Tropin

 doc/guix.texi | 209 +-
 1 file changed, 205 insertions(+), 4 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 333cb4117a..a48fb0e2b7 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -35652,10 +35652,11 @@ them in an @code{operating-system} declaration.  But 
how do we define
 them in the first place?  And what is a service anyway?
 
 @menu
-* Service Composition:: The model for composing services.
-* Service Types and Services::  Types and services.
-* Service Reference::   API reference.
-* Shepherd Services::   A particular type of service.
+* Service Composition::The model for composing services.
+* Service Types and Services:: Types and services.
+* Service Reference::  API reference.
+* Shepherd Services::  A particular type of service.
+* Writing Service Configurations:: A guideline for writing guix services.
 @end menu
 
 @node Service Composition
@@ -35851,6 +35852,206 @@ There can be only one instance of an extensible 
service type such as
 Still here?  The next section provides a reference of the programming
 interface for services.
 
+@node Writing Service Configurations
+@subsection Writing Service Configurations
+
+There are a lot of system and home services already written, but from
+time to time it's necessary to write one more.  This section contains
+tips for simplifying this process, and should help to make service
+configurations and their implementations more consistent.
+
+@quotation Note
+If you find any exceptions or patterns missing in this section, please
+send a patch with additions/changes to @email{guix-devel@@gnu.org}
+mailing list or just start a discussion/ask a question.
+@end quotation
+
+@subsubheading Configuration Itself
+
+As we know from previous section a guix service can accept a value and
+be extended with additional values by other services.  There are some
+cases, when the service accepts a list of pairs or some other values for
+example @code{console-font-service-type} accepts list of pairs (tty and
+font name/file) or @code{etc-service-type} accepts list of lists
+(resulting file name and file-like object), those services are kinda
+special, they are an intermediate helpers doing auxiliary work.
+
+However, in most cases a guix service is wrapping some software, which
+consist of package or a few packages, and configuration file or files.
+Therefore, the value for such service is quite complicated and it's hard
+to represent it with a just list or basic data type, in such cases we
+use a record.  Each such record have -configuration suffix, for example
+@code{docker-configuration} for @code{docker-service-type} and a few
+different fields helping to customize the software.  Configuration
+records for home services also have a @code{home-} prefix in their name.
+
+There is a module @code{gnu service configuration}, which contains
+helpers simplifying configuration definition process.  Take a look at
+@code{gnu services docker} module or grep for
+@code{define-configuration} to find usage examples.
+
+@c Provide some examples, tips, and rationale behind @code{gnu service
+@c configuration} module.
+
+After a configuration record properly named and defined let's discuss
+how to name and define fields, and which approach to use for
+implementing the serialization code related to them.
+
+@subsubheading Configuration Record Fields
+
+@enumerate
+@item
+It's a good idea to have a field/fields for specifying package/packages
+being installed for this service.  For example
+@code{docker-configuration} has @code{docker}, @code{docker-cli},
+@code{containerd} fields.  Sometimes it make sense to make a field,
+which accepts a list of packages for cases, where an arbitrary list of
+plugins can be passed to the configuration.  There are some services,
+which provide a field called @code{package} in their configuration,
+which is ok, but the way it done in @code{docker-configuration} is more
+flexible and thus preferable.
+
+@item
+Fields for configuration files, should be called the same as target
+configuration file name, but in kebab-case: bashrc for bashrc,
+bash-profile

Re: SSH service for Guix Home

[Andrew Tropin]

On 2021-12-17 15:21, Xinglu Chen wrote:

> Hi,
>
> On Wed, Dec 15 2021, Ludovic Courtès wrote:
>
>> Hi Andrew,
>>
>> One service I miss for Guix Home is ‘home-ssh-service-type’, which is in
>> the “original” Guix Home.
>>
>> Could you contribute a patch adding it?  (I could do it on your behalf,
>> but it sounds more logical to let you handle it.)
>
> Being the original author, I will hopefully try to work on it soon.  :-)
>

It works for me.  Would be very glad if you accomplish it.

>> Also, could you (or Xinglu, or Oleg) write a blog post for
>> guix.gnu.org, targeting an audience who’s not familiar with this kind
>> of tool, making it clear what the rationale is and what it can bring
>> to “normal users”?  It would be really helpful to have that published
>> within a couple of weeks or so, before the next release.
>
> That sounds like a good idea, I would be happy to help!
>

I will make a patch with skeleton of the post and will send it to you
and mailing list for review and discussion.  I think it is the easiest
way to cooperate on a blog post.

>> Last, it’d be great to see the three of you (and more people!) back in
>> action regarding Guix Home.  I understand that life sometimes gets in
>> the way, but it seems that there’s been some confusion as to how to go
>> forward—e.g., <https://issues.guix.gnu.org/51359#2>—which may partly
>> explain why things stalled.  If there are patches waiting for review,
>> also don’t hesitate to ping!
>
> Yeah, apologies for not being very active in the last few months.
>
> I think one of the problems is that there is not really any style guide
> for now to write services (I do have a WIP patch in my local tree that
> will document most of (gnu services configuration) though :-)).  We also
> lack a way to properly test home services; we would need something
> similar to what Nix Home-manager has[1][2].
>
> [1]: Nix code for configuring a program
> <https://github.com/nix-community/home-manager/blob/master/tests/modules/programs/git/git.nix>
> [2]: Expected content of the serialized configuration
> <https://github.com/nix-community/home-manager/blob/master/tests/modules/programs/git/git-expected.conf>
>

Yep, having a workflow for writing guix service's tests will be also
cool.  I see a few files in test/services/, but it doesn't seem to have
a well-established approach, just a few functional tests.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: SSH service for Guix Home

[Andrew Tropin]

On 2021-12-15 18:59, Ludovic Courtès wrote:

> Hi Andrew,
>

Hi Ludovic!

> One service I miss for Guix Home is ‘home-ssh-service-type’, which is
> in the “original” Guix Home.
>
> Could you contribute a patch adding it?  (I could do it on your behalf,
> but it sounds more logical to let you handle it.)

Yep, I'll try to do it soon.

>
> Also, could you (or Xinglu, or Oleg) write a blog post for guix.gnu.org,
> targeting an audience who’s not familiar with this kind of tool, making
> it clear what the rationale is and what it can bring to “normal users”?
> It would be really helpful to have that published within a couple of
> weeks or so, before the next release.

I have a blog post task in my backlog, I want to upstream more home
services before publishing the post.  It's not a blocker, but a nice
thing to have.  There is another ongoing work, which I would like to
finish before making a post.

Another option is to publish this post some time after 1.4.0 release, so
everything I want will be finished to that moment.  I don't see reasons
to hurry, so it's a viable alternative too.

>
> Last, it’d be great to see the three of you (and more people!) back in
> action regarding Guix Home.  I understand that life sometimes gets in
> the way, but it seems that there’s been some confusion as to how to go
> forward—e.g., <https://issues.guix.gnu.org/51359#2>—which may partly
> explain why things stalled.  If there are patches waiting for review,
> also don’t hesitate to ping!

I burnt out a little during upstreaming process, it was quite slow and
painful at the beginning and increased maintanance burden of rde for me.
A little too early merge + uncoordinated changes of basic primitives and
service configurations also hit me quite hard and forced to spend some
time bringing rde back to working state without going a step further.

I took a break and after that started to cleanup small Guix Home issues,
develop/improve home services in rde repo and finally started to work on
new rde features.  Still feel a little burnt out and I try not to do
worse.


Now to more technical details:

When I started to work on Guix Home I explored different system services
configurations and tried to extract some common patterns, it was
relatively hard, cause of implementation inconsistencies.  I wrote
notes, extracted most common patterns and come with some approach for
writing service configurations.  During development of Guix Home it was
slightly changed, but most of the home service implementations are
consistent.

gexp -> file-like change done in Guix repo for shell service
configurations and text-config type partially breaks the ideas I have
about how services should be implemented.

To continue upstreaming home services from rde to Guix I would like and
actually need to have an established style guide on how to write service
configurations to make sure service implementations are consistent.  I
started to write a manual section, which we can collectively review,
discuss and adjust it to get such a style guide.  Cause of burn out and
a lot of unrewarding monkey work I've done recently it's a little hard
to focus on this task, but I'll try to send first drafts to mailing list
soon.

So there is some work happening, but maybe not so visible.


Sorry for being not very active on ML recently, hope after core-updates
merged now you have a little more free time, so we can faster reach the
agreement on service implementation style guide and more people will be
able to contribute high quality services for both Guix System and Guix
Home.

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Merging wip-guix-home to master

[Andrew Tropin]

On 2021-09-29 13:39, Xinglu Chen wrote:

> On Tue, Sep 28 2021, Andrew Tropin wrote:
>
>> On 2021-09-24 15:38, Xinglu Chen wrote:
>>
>>> On Thu, Sep 23 2021, Andrew Tropin wrote:
>>>
>>>> The core part of Guix Home project has been moved from rde
>>>> repository[fn:1] to wip-guix-home branch of guix repository.
>>>>
>>>> I'm about a week on wip-guix-home branch completely and Guix Home works
>>>> fine.  There are no any major issues on rde-devel and guix-devel mailing
>>>> lists and it seems that branch is ready to be merged.
>>>>
>>>> My guix describe looks like:
>>>> --8<---cut here---start->8---
>>>> Generation 114 Sep 17 2021 13:33:55(current)
>>>>   rde 31f8003
>>>> repository URL: https://git.sr.ht/~abcdw/rde
>>>> branch: without-guix-home
>>>> commit: 31f800353a781cef25fc80c05ad824a068a049c8
>>>>   guix a2324d8
>>>> repository URL: https://git.savannah.gnu.org/git/guix.git
>>>> branch: wip-guix-home
>>>> commit: a2324d8b56eabf8117bca220a507cc791edffd2e
>>>> --8<---cut here---end--->8---
>>>>
>>>>
>>>> There is a discussion[fn:2] on moving home services to (gnu services
>>>> ...)  modules, which is likely to happen, but it's possible to do the
>>>> migration relatively painless by re-exporting necessary symbols in
>>>> (gnu home-services ...) at first and removing them completely later.
>>>>
>>>> Another important part of the work related to Guix Home project is
>>>> covering related modules and cli with tests, but it can be done in
>>>> parallel and is not a blocker for merging.
>>>
>>> I noticed that the ‘guix home import’ subcommand is included, but I
>>> think it needs more thought and feedback from people before it makes its
>>> way into ‘master’; it also seems to lack documentation.
>>>
>>> I just realized that it generates the following service declaration
>>>
>>> --8<---cut here---start->8---
>>> (service
>>>  home-bash-service-type
>>>  (home-bash-configuration
>>>   (bashrc
>>>(list (slurp-file-gexp
>>>   (local-file "/home/yoctocell/.bashrc"))
>>> --8<---cut here---end--->8---
>>>
>>> but when running ‘guix home reconfigure’, the ~/.bashrc file will be
>>> moved, so when running ‘guix home reconfigure’ for the second time, it
>>> would read the ~/.bashrc which is itself a symlink to a file the store.
>>> ‘guix home import’ clearly isn’t in a usable state as of right now…
>>
>> Yep, I remember that it is not documented.  I think it's ok for
>> generating a simple sample configuration,

It was two independent sentences.

>
> I disagree, I think it’s OK for things like (guix git), which are mainly
> used by developers, to not be documented in the manual.  Ideally, the
> all the modules would be documented.  :-)
>
> However, ‘guix home import’ will be used by developers and regular
> users, and documenting the command should be a requirement.
>
>> but I agree that it's not yet complete, if you wish I'll disable it in
>> cli.
>
> I have sent a few patches to fix it and document it[1], so it should
> probably left as-is for now.
>
>> Just an idea for the future: it's probably better to copy .bashrc to the
>> current directory and do (local-file "./bashrc").
>
> This wouldn’t work if the user doesn’t have write-access to the current
> directory, nor if the current directory is $HOME.  I think it’s better
> for the user to specify the directory themselves.
>
> [1]: <https://issues.guix.gnu.org/50873>


signature.asc
Description: PGP signature

Re: On the naming of System and Home services modules.

[Andrew Tropin]

On 2021-09-28 14:26, Ludovic Courtès wrote:

> Hi,
>
> (+ Cc: Oleg.)
>
> Andrew Tropin  skribis:
>
>> For now my personal ranking of the ideas is following:
>>
>> 1. Move to (gnu services ...) :: can(?) provide some additional reusability.
>> 2. Keep as it is right now (gnu home-services ...) :: already works.
>> 3. Move to (gnu home services ...) :: good stylistic change, but breaks
>> backward compatibility.
>
> As I stated in another message, backward compatibility is not a concern
> here from the Guix POV (of course it’s a concern for those who were
> already using pre-merge Guix Home, but for Guix all these APIs are new.)
>
> (As an aside, part of the reason I asked a few days ago to have more
> time for review was precisely so we could refine the APIs before it goes
> public.)
>
> I would very much like to have these modules renamed to (gnu home
> services …) quickly.  WDYT?  Could the two of you take a look?

Doable.

What about moving home services to (gnu services ...)?

It's a little harder, because we probably will need to adjust `guix
system search` and `guix home search`, but other than that seems not too
hard.

However, I'm quite ok with (gnu home services ...), just asking to avoid
one more migration later.

Let me know, which option seems better to you, I can take this task
tomorrow.

>
> Thanks,
> Ludo’.


signature.asc
Description: PGP signature

Re: Merging wip-guix-home to master

[Andrew Tropin]

On 2021-09-24 15:38, Xinglu Chen wrote:

> On Thu, Sep 23 2021, Andrew Tropin wrote:
>
>> The core part of Guix Home project has been moved from rde
>> repository[fn:1] to wip-guix-home branch of guix repository.
>>
>> I'm about a week on wip-guix-home branch completely and Guix Home works
>> fine.  There are no any major issues on rde-devel and guix-devel mailing
>> lists and it seems that branch is ready to be merged.
>>
>> My guix describe looks like:
>> --8<---cut here---start->8---
>> Generation 114   Sep 17 2021 13:33:55(current)
>>   rde 31f8003
>> repository URL: https://git.sr.ht/~abcdw/rde
>> branch: without-guix-home
>> commit: 31f800353a781cef25fc80c05ad824a068a049c8
>>   guix a2324d8
>> repository URL: https://git.savannah.gnu.org/git/guix.git
>> branch: wip-guix-home
>> commit: a2324d8b56eabf8117bca220a507cc791edffd2e
>> --8<---cut here---end--->8---
>>
>>
>> There is a discussion[fn:2] on moving home services to (gnu services
>> ...)  modules, which is likely to happen, but it's possible to do the
>> migration relatively painless by re-exporting necessary symbols in
>> (gnu home-services ...) at first and removing them completely later.
>>
>> Another important part of the work related to Guix Home project is
>> covering related modules and cli with tests, but it can be done in
>> parallel and is not a blocker for merging.
>
> I noticed that the ‘guix home import’ subcommand is included, but I
> think it needs more thought and feedback from people before it makes its
> way into ‘master’; it also seems to lack documentation.
>
> I just realized that it generates the following service declaration
>
> --8<---cut here---start->8---
> (service
>  home-bash-service-type
>  (home-bash-configuration
>   (bashrc
>(list (slurp-file-gexp
>   (local-file "/home/yoctocell/.bashrc"))
> --8<---cut here---end--->8---
>
> but when running ‘guix home reconfigure’, the ~/.bashrc file will be
> moved, so when running ‘guix home reconfigure’ for the second time, it
> would read the ~/.bashrc which is itself a symlink to a file the store.
> ‘guix home import’ clearly isn’t in a usable state as of right now…

Yep, I remember that it is not documented.  I think it's ok for
generating a simple sample configuration, but I agree that it's not yet
complete, if you wish I'll disable it in cli.

Just an idea for the future: it's probably better to copy .bashrc to the
current directory and do (local-file "./bashrc").


signature.asc
Description: PGP signature

Re: On the naming of System and Home services modules.

[Andrew Tropin]

On 2021-09-23 22:10, Ludovic Courtès wrote:

> Hi,
>
> Andrew Tropin  skribis:
>
>> However, ~(gnu home services ...)~ also looks cool, but it would be a
>> little inconsistent with system services, which will have one level of
>> nestiness less: ~(gnu services)~.
>>
>> IMO, ~(gnu home services ...)~ would be a good choice if we use ~(gnu
>> system services)~ for system services.
>
> Regarding naming, I agree that what you propose would be more
> consistent, but we’re not going to rename Guix System modules just now.
> :-)
>
> So, from a purely cosmetic standpoint, I’d still prefer (gnu home
> services …) rather than (gnu home-services …).  It’s more consistent
> with the rest IMO.
>
> Thanks,
> Ludo’.

Ok, got the remark, will think on this topic a little more.

For now my personal ranking of the ideas is following:

1. Move to (gnu services ...) :: can(?) provide some additional reusability.
2. Keep as it is right now (gnu home-services ...) :: already works.
3. Move to (gnu home services ...) :: good stylistic change, but breaks
backward compatibility.



signature.asc
Description: PGP signature

Re: Code sharing between system and home services (was Re: On the naming of System and Home services modules.)

[Andrew Tropin]

On 2021-09-24 16:03, Maxime Devos wrote:

> Xinglu Chen schreef op vr 24-09-2021 om 15:35 [+0200]:
>> On Thu, Sep 23 2021, Ludovic Courtès wrote:
>> 
>> > Hi,
>> > 
>> > Xinglu Chen  skribis:
>> > 
>> > > Some services might be useful to have in both Guix System and Guix Home;
>> > > for instance, Guix System currently has a service for configuring
>> > > Syncthing, and I think it makes sense to also have one for Guix Home,
>> > > this would mean that people not using Guix System (me :-)) could also
>> > > have Guix manage Syncthing.  With the current approach, we would have to
>> > > copy and paste quite a bit of code, and if the Syncthing service for
>> > > Guix System changes, then the one for Guix Home might have to change as
>> > > well.
>> > 
>> > Silly question, but why do we need to have two different configuration
>> > record types in the first place?
>> 
>> The problem is that the configuration records for system and home
>> service don’t necessarily have the same fields.  The Syncthing service
>> for Guix System has a ‘user’ and a ‘group’ field, which is not really of
>> any use in Guix Home, as the only user would be the user invoking ‘guix
>> home’.
>> 
>> > Sharing configuration between Home and System sounds important to me: it
>> > means users can easily move services from one to the other, which is
>> > pretty big deal.  It also means we’d have much less code to maintain.
>> 
>> Agreed, that’s what I would like to see as well.
>> 
>> > Would that be feasible?  (Apologies if this has already been
>> > discussed!)
>> 
>> Since it might not make sense to have the same records fields for a
>> system service and home service, I proposed (in the mail you replied to)
>> a ‘define-configuration’ form that would generate a configuration record
>> for a system service and optionally one for a home service, without
>> having to maintain two records separately.
>> 
>> --8<---cut here---start->8---
>> (define-configuration syncthing-configuration
>>   (package
>>(package syncthing)
>>"Syncthing package to use.")
>>   (arguments
>>(list-of-strings ’())
>>"Command line arguments to pass to the Syncthing package.")
>>   (log-flags
>>(integer 0)
>>"Sum of logging flags.")
>>   (user
>>(maybe-string 'disabled)
>>"The user as which the Syncthing service is to be run."
>>(home-service? #f))  ; not for Guix Home
>>   (group
>>(string "users")
>>"The group as which the Syncthing service is to be run."
>>(home-service? #f))  ; likewise ^^
>>   (home
>>(maybe-string 'disabled)
>>"Common configuration and data directory.")
>>   (home-service? #t))
>> --8<---cut here---end--->8---
>> 
>> It would generate  and
>> .  The only difference being that
>>  doesn’t have a ‘user’ and a ‘group’
>> field.
>
> The 'parent' mechanism (rnrs records syntactic) 'parent' could be used
> here (after adapting it to define-configuration), to define three record 
> types:
>
> The record type with all fields common to the home configuration and system 
> configuration
> ( + common-syncthing-configuration?)
> and the record types for the home and system configuration
> ( + syncthing-configuration? and 
> 
> + home-syncthing-configuration?).
>
> Using this mechanism, all syncthing-configuration? and 
> home-syncthing-configuration?
> are common-syncthing-configuration?.
>
> Greetings,
> Maxime.

It can work.  Good idea.


signature.asc
Description: PGP signature

Re: On the naming of System and Home services modules.

[Andrew Tropin]

On 2021-09-23 22:08, Ludovic Courtès wrote:

> Hi,
>
> Xinglu Chen  skribis:
>
>> Some services might be useful to have in both Guix System and Guix Home;
>> for instance, Guix System currently has a service for configuring
>> Syncthing, and I think it makes sense to also have one for Guix Home,
>> this would mean that people not using Guix System (me :-)) could also
>> have Guix manage Syncthing.  With the current approach, we would have to
>> copy and paste quite a bit of code, and if the Syncthing service for
>> Guix System changes, then the one for Guix Home might have to change as
>> well.
>
> Silly question, but why do we need to have two different configuration
> record types in the first place?

1. Different fields (for example system services in many cases wants to
know the username, which will be used to run process from, home services
will probably use the user's username and won't rely on this field, home
services on the other hand can have something like xdg-flavor? or
anything else unrelated to system services).

Even if fields are not conflicting with each other, it's very likely
that it will introduce a confusion: user of Guix Home on foreign distro
will be guessing why there is a field in configuration record, which
doesn't make sense for a home service.

2. Different default values.  $HOME/mail or /var/spool/mail? Even if we
can technically bypass those problems, semantically the values will be
incorrect.

There are possible solutions to that, like making home-extra-settings
and system-extra-settings fields, which will contain records with
fields, which are different for those services, but I'm not sure if all
the hussle is worth it.

>
> Sharing configuration between Home and System sounds important to me: it
> means users can easily move services from one to the other, which is
> pretty big deal.  It also means we’d have much less code to maintain.
>
> Would that be feasible?  (Apologies if this has already been discussed!)

I find records to be a very rigid and hard to reuse and probably we have
to have separate sets of configuration records as I mentioned earlier in
the thread, but the auxiliary functions seems quite reusable.

>
> Also, I proposed earlier a possible way to generate a Home service type
> from the corresponding System service type—or, IOW, to generate a Home
> service type graph from the System graph.  Does that sound feasible?

Not sure what you mean here, can you share a link to the proposal or
elaborate one more time, please.

>
> Thanks,
> Ludo’.


signature.asc
Description: PGP signature

Re: Merging wip-guix-home to master

[Andrew Tropin]

On 2021-09-23 22:45, Ludovic Courtès wrote:

> Hi,
>
> Andrew Tropin  skribis:
>
>> I'm about a week on wip-guix-home branch completely and Guix Home works
>> fine.  There are no any major issues on rde-devel and guix-devel mailing
>> lists and it seems that branch is ready to be merged.
>
> Yay!  I’d like to take another look (I know I’ve been terribly MIA,
> apologies!), and I hope other folks familiar with Guix System can
> comment as well.

Sure, let's wait for reviews/comments until next Thursday.

>
>> There is a discussion[fn:2] on moving home services to (gnu services
>> ...)  modules, which is likely to happen, but it's possible to do the
>> migration relatively painless by re-exporting necessary symbols in
>> (gnu home-services ...) at first and removing them completely later.
>
> I know it can be annoying to existing Guix Home users, but I’d prefer
> not to carry pre-merge baggage; that is, we’d just rename and not
> provide those modules under their former names at all.
>

Yep, it is very likely that it will be annoying, but I think it's
doable.  It should be a relatively simple migration for users.

>> Another important part of the work related to Guix Home project is
>> covering related modules and cli with tests, but it can be done in
>> parallel and is not a blocker for merging.
>
> Do you have ideas of a possible testing strategy?

Yep, I think we can do the same thing to tests/guix-system.sh, check
that `guix home build` provides desired results on simple configurations
and `guix home search` shows correct results on different input strings.

>
> We should be able to test at least the CLI, either arranging to avoid
> large builds (as in tests/guix-build.sh) or talking to the “real”
> guix-daemon (as in tests/guix-pack-relocatable.sh) if we’re going to
> need packages.
>
> It’d be great to have this part ready soonish.

I hope to work on it next week.

>
> The way I see it, in 1.4 (2.0?), we’d mark Guix Home as a “technology
> preview” in the manual with a prominent note.  That will allow us to get
> feedback from new users and to fine-tune code correspondingly, and
> that’ll make it clear to users that things are still subject to change.

Marked it as a subject to change in Home Configuration section of the
manual, patch in the reply to Oleg.

>
> Thoughts?
>
> Thanks,
> Ludo’.


signature.asc
Description: PGP signature

Re: Merging wip-guix-home to master

[Andrew Tropin]

On 2021-09-23 10:27, Katherine Cox-Buday wrote:

> Andrew Tropin  writes:
>
>> The core part of Guix Home project has been moved from rde
>> repository[fn:1] to wip-guix-home branch of guix repository.
>>
>> I'm about a week on wip-guix-home branch completely and Guix Home works
>> fine.  There are no any major issues on rde-devel and guix-devel mailing
>> lists and it seems that branch is ready to be merged.
>
> I just want to thank you for the work. I don't think I'll use this 
> everywhere, but it is definitely going to be helpful in some environments. 
> Thank you!

My pleasure)


signature.asc
Description: PGP signature

Merging wip-guix-home to master

[Andrew Tropin]

The core part of Guix Home project has been moved from rde
repository[fn:1] to wip-guix-home branch of guix repository.

I'm about a week on wip-guix-home branch completely and Guix Home works
fine.  There are no any major issues on rde-devel and guix-devel mailing
lists and it seems that branch is ready to be merged.

My guix describe looks like:
--8<---cut here---start->8---
Generation 114  Sep 17 2021 13:33:55(current)
  rde 31f8003
repository URL: https://git.sr.ht/~abcdw/rde
branch: without-guix-home
commit: 31f800353a781cef25fc80c05ad824a068a049c8
  guix a2324d8
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: wip-guix-home
commit: a2324d8b56eabf8117bca220a507cc791edffd2e
--8<---cut here---end--->8---


There is a discussion[fn:2] on moving home services to (gnu services
...)  modules, which is likely to happen, but it's possible to do the
migration relatively painless by re-exporting necessary symbols in
(gnu home-services ...) at first and removing them completely later.

Another important part of the work related to Guix Home project is
covering related modules and cli with tests, but it can be done in
parallel and is not a blocker for merging.

* Footnotes

[fn:1] https://git.sr.ht/~abcdw/rde

[fn:2] https://lists.gnu.org/archive/html/guix-devel/2021-09/msg00169.html


signature.asc
Description: PGP signature

Re: On the naming of System and Home services modules.

[Andrew Tropin]

On 2021-09-17 11:28, Xinglu Chen wrote:

> On Thu, Sep 16 2021, Andrew Tropin wrote:
>
>>>> * Putting Home Services to ~(gnu services ...)~
>>>> In the thread https://issues.guix.gnu.org/49419#18 Ludovic suggested:
>>>>
>>>>> Regarding module names: what about putting everything in the (gnu
>>>>> home …) name space.  For services, I wonder if we could simply use
>>>>> (gnu services home), for the essential services, and other (gnu
>>>>> services …) module, but that assumes some code can be shared between
>>>>> System and Home.  Thoughts?
>>>>
>>>> ** Shortcomings
>>>> While it's a nice idea, I see some shortcomings here:
>>>>
>>>> *** Code Reuse
>>>> Mcron, Shepherd and a few other fundamental pieces are reused between
>>>> Guix Home and Guix System, but it's easily done by exporting a few
>>>> symbols from related modules.
>>>>
>>>> Records even for the same services have slightly different fields and
>>>> because of macro nature can't be reused between Home and System
>>>> services. In more details I mentioned this problem here:
>>>> https://lists.sr.ht/~abcdw/rde-devel/%3C87y2cqifpx.fsf%40yoctocell.xyz%3E#%3c878s4l8kai@trop.in%3E
>>>
>>> Some services might be useful to have in both Guix System and Guix Home;
>>> for instance, Guix System currently has a service for configuring
>>> Syncthing, and I think it makes sense to also have one for Guix Home,
>>> this would mean that people not using Guix System (me :-)) could also
>>> have Guix manage Syncthing.  With the current approach, we would have to
>>> copy and paste quite a bit of code, and if the Syncthing service for
>>> Guix System changes, then the one for Guix Home might have to change as
>>> well.
>>>
>>
>> We can extract parts, which have to be in sync between home service and
>> system service and just use them in both.  I don't see how placing home
>> service in the same module will decrease the amount of "copy-paste".
>>
>> If you talk about "shared" fields for configuration records, it's
>> probably true, but I don't see any good solution yet.  I'm unhappy that
>> records are implemented with macros, because it complicates the
>> extensibility of the mechanism, wrapping them in more macros doesn't
>> make thing better IMO.
>
> Since we don’t have a way to avoid using macros for records, resisting
> macros probably won’t really help much.  :-)
>

The fact that we already use them doesn't mean that we need to use more
macros, IMO it's a good idea to keep the amount of macros as small as
possible.

>>> I have thought about a ‘define-configuration’ macro that would
>>> generate one configuration record for Guix system and optionally,
>>> one for Guix Home.  For example
>>>
>>>   (define-configuration syncthing-configuration
>>> ...)
>>>
>>> would work as it currently does, and
>>>
>>>   (define-configuration syncthing-configuration
>>> ...
>>> (home-service? #t))
>>>
>>> would generate a  record and a
>>>  record.
>>>
>>> There is the problem of  and
>>>  not having the same fields.  To solve
>>> this, Each clause could have an ‘home-service?’ field, and the code
>>> would look like
>>>
>>>   (define-configuration syncthing-configuration
>>> (package
>>>  (package syncthing)
>>>  "Syncthing package to use.")
>>> (arguments
>>>  (list-of-strings ’())
>>>  "Command line arguments to pass to the Syncthing package.")
>>> (log-flags
>>>  (integer 0)
>>>  "Sum of logging flags.")
>>> (user
>>>  (maybe-string 'disabled)
>>>  "The user as which the Syncthing service is to be run."
>>>  (home-service? #f))  ; not for Guix Home
>>> (group
>>>  (string "users")
>>>  "The group as which the Syncthing service is to be run."
>>>  (home-service? #f))  ; likewise ^^
>>> (home
>>>  (maybe-string 'disabled)
>>>  "Common configuration and data directory.")
>>> (home-service? #t))
>>>
>>> This would mean that  would have all the
>>> fields, but  would have all but the ‘user’
>>> and ‘group’ fields.
>>>
>>> We could

Re: On the naming of System and Home services modules.

[Andrew Tropin]

On 2021-09-15 09:50, Katherine Cox-Buday wrote:

> Xinglu Chen  writes:
>
>> On Wed, Sep 15 2021, Andrew Tropin wrote:
>
>>> Records even for the same services have slightly different fields and
>>> because of macro nature can't be reused between Home and System
>>> services. In more details I mentioned this problem here:
>>> https://lists.sr.ht/~abcdw/rde-devel/%3C87y2cqifpx.fsf%40yoctocell.xyz%3E#%3c878s4l8kai@trop.in%3E
>>
>> Some services might be useful to have in both Guix System and Guix Home;
>> for instance, Guix System currently has a service for configuring
>> Syncthing, and I think it makes sense to also have one for Guix Home,
>> this would mean that people not using Guix System (me :-)) could also
>> have Guix manage Syncthing.  With the current approach, we would have to
>> copy and paste quite a bit of code, and if the Syncthing service for
>> Guix System changes, then the one for Guix Home might have to change as
>> well.
>
> I agree with this point. I have several Guix systems, and several
> non-guix systems with Guix managing some services. In the past, I have
> had to write my own Shepherd services for things already written as
> system services.
>

Shouldn't be a problem, if home service will be a prefered option.
More details on that in the reply to Xinglu, look for linger keyword. 

>
>>> The intersection of home and system services should be very low, so
>>> there is not much benifit here as well.
>>
>> Quite the opposite, I think it would be great if home and system
>> services could integrate more with each other.  In NixOS, the NixOS
>> modules and Home Manager modules feel like two very distinct things, and
>> it’s not really easy to share things between them.
>
> I agree.
>
>>> ** Summary
>>> Let's keep System and Home services separate for the sake of clarity,
>>> reuse code via shared modules or just exports in (gnu services ...).
>
> [...]
>
>>> However, ~(gnu home services ...)~ also looks cool, but it would be a
>>> little inconsistent with system services, which will have one level of
>>> nestiness less: ~(gnu services)~.
>>>
>>> IMO, ~(gnu home services ...)~ would be a good choice if we use ~(gnu
>>> system services)~ for system services.
>>
>> Yeah, having both (gnu system service) and (gnu home service) could make
>> sense, but since we only have (gnu services), I don’t think it makes
>> much sense.
>
> I haven't put in the energy to follow the rational behind the proposed
> naming schemas, but I'd like to suggest this as well: =(gnu services
> home)=. This namespace increases in specificity, and I think it would
> easily follow that things in =(gnu services home)= might utilize things
> in =(gnu services)=. Or I also like the idea of =home= and =system=
> being sibling namespaces.

Actually a good idea, thank you, I will consider it.


signature.asc
Description: PGP signature

Re: On the naming of System and Home services modules.

[Andrew Tropin]

On 2021-09-15 15:06, Xinglu Chen wrote:

> On Wed, Sep 15 2021, Andrew Tropin wrote:
>
>> This topic was raised a few times during development of Guix Home
>> project and also during the review of wip-guix-home branch.  I made a
>> separate thread to do an exhaustive discussion of it.
>>
>> * Services and Confusion
>> It's an optional section, you can skip it, but I still find it somehow
>> related to the topic.
>>
>> I want to re-raise the issue related to system services concept.  When
>> I started using Guix I found system services to be confusing,
>> originally I thought it's a way to declare services managed by init
>> system, but later I realised that only some of system services becomes
>> Shepherd services and many of them doesn't.  It's not a unique problem
>> I see this issue appear again and again in different Guix chats and
>> communities.
>>
>> - System services :: just building blocks, nodes of DAG representing
>> a system, which after folding, results in a complete operating system
>> or other artifact.
>> - Shepherd services :: long-living processes/daemons managed by init
>> system or user-space Shepherd. It's what people used to refer as services.
>>
>> It will be very hard and costly to rename system services to something
>> less confusing, but at least let's try to keep those concepts as
>> distinct as possible.  Probably originally system and Shepherd
>> services were closely related, but not now, so let's express it very
>> clearly in docs/chats/mailing lists.
>>
>> Another player on this field is "home services", which is a similar to
>> system services, but used for describing a separate DAG, which after
>> folding, results in home environment (artifact containing user's
>> program configurations and profile with packages declared by user).
>>
>> * Putting Home Services to ~(gnu services ...)~
>> In the thread https://issues.guix.gnu.org/49419#18 Ludovic suggested:
>>
>>> Regarding module names: what about putting everything in the (gnu
>>> home …) name space.  For services, I wonder if we could simply use
>>> (gnu services home), for the essential services, and other (gnu
>>> services …) module, but that assumes some code can be shared between
>>> System and Home.  Thoughts?
>>
>> ** Shortcomings
>> While it's a nice idea, I see some shortcomings here:
>>
>> *** Code Reuse
>> Mcron, Shepherd and a few other fundamental pieces are reused between
>> Guix Home and Guix System, but it's easily done by exporting a few
>> symbols from related modules.
>>
>> Records even for the same services have slightly different fields and
>> because of macro nature can't be reused between Home and System
>> services. In more details I mentioned this problem here:
>> https://lists.sr.ht/~abcdw/rde-devel/%3C87y2cqifpx.fsf%40yoctocell.xyz%3E#%3c878s4l8kai@trop.in%3E
>
> Some services might be useful to have in both Guix System and Guix Home;
> for instance, Guix System currently has a service for configuring
> Syncthing, and I think it makes sense to also have one for Guix Home,
> this would mean that people not using Guix System (me :-)) could also
> have Guix manage Syncthing.  With the current approach, we would have to
> copy and paste quite a bit of code, and if the Syncthing service for
> Guix System changes, then the one for Guix Home might have to change as
> well.
>

We can extract parts, which have to be in sync between home service and
system service and just use them in both.  I don't see how placing home
service in the same module will decrease the amount of "copy-paste".

If you talk about "shared" fields for configuration records, it's
probably true, but I don't see any good solution yet.  I'm unhappy that
records are implemented with macros, because it complicates the
extensibility of the mechanism, wrapping them in more macros doesn't
make thing better IMO.

> 
> I have thought about a ‘define-configuration’ macro that would
> generate one configuration record for Guix system and optionally, one
> for Guix Home.  For example
>
>   (define-configuration syncthing-configuration
> ...)
>
> would work as it currently does, and
>
>   (define-configuration syncthing-configuration
> ...
> (home-service? #t))
>
> would generate a  record and a
>  record.
>
> There is the problem of  and
>  not having the same fields.  To solve
> this, Each clause could have an ‘home-service?’ field, and the code
> would look like
>
>   (define-configuration syncthing-configuration
> (package
>  (package s

Re: On the naming of System and Home services modules.

[Andrew Tropin]

On 2021-09-16 03:05, Ryan Prior wrote:

> On Wednesday, September 15th, 2021 at 8:47 AM, Andrew Tropin
>> People will be trying to use home services inside operating systems, and 
>> configuration record for system services inside home services.
>
> I think it will be a dismal design failure if we cannot make this just
> work the way people would expect. Why should we accept that a service
> which can be run as your user (a "home" service) cannot be run as the
> system, or vice versa?
>
> Perhaps there are some services that only make sense on the system
> (for example, I don't suppose a home service defining Linux kernel
> modules would be appropriate.) So for those corner cases perhaps we
> must allow marking home-only or system-only services, and make it an
> error to put one in the other's place. But isn't it the common case
> that a service declaration can be part of the home or the system, and
> this merely changes some details in how the thing is run and what
> fields are required for its configuration?
>
> Ryan

It's not technically possible with current service extension mechanism
to have a service, which can be used in both operating-system and
home-environment.  You can read more on possible improvements to
extension mechanism here:
https://lists.sr.ht/~abcdw/rde-devel/%3C87sg56g97i.fsf%40trop.in%3E

However, currently it's just impossible without a huge (and probably
backward incompatible) refactoring of service extension mechanism and
perhaps all the services.

Even if it would be possible, still don't see too much cases, where the
system service is wanted to be used as home service and vice versa.



signature.asc
Description: PGP signature

Re: On the naming of System and Home services modules.

[Andrew Tropin]

On 2021-09-15 12:09, Maxime Devos wrote:

> Andrew Tropin schreef op wo 15-09-2021 om 11:47 [+0300]:
>> *** Confusion
>> I already mentioned that I see a lot of confusion between System and
>> Shepherd services and I expect some confusion between home and system
>> services, it will be especially true if we place them in the same
>> namespace.
>> 
>> People will be trying to use home services inside operating systems,
>> #+begin_src scheme
>> (operating-system
>>   (services
>>(list (service home-mcron-service-type ...
>> #+end_src
>> 
>> and configuration record for system services inside home services.
>> #+begin_src scheme
>> (home-environment
>>  ... (service home-mcron-service-type
>>   (mcron-configuration ...)))
>> #+end_src
>
> What do you think of adding some validation code to 'service-type'
> and the "guix home" equivalent, e.g. a ‘validate’ field, which
> could be used like
>
> (define-module (...)
>   #:autoload (gnu home??? mcron) (mcron-user-configuration?))
>
> (define mcron-service-type
>   (service-type (name 'mcron)
> ...
> (validate
>   (lambda (config)
> (cond ((mcron-configuration? config) #t)
>   ((home-mcron-configuration? config)
>;; TODO: figure out a clear error message
>(validation-error (G_ "A mcron configuration for 
> the system was expected, but a configuration for the user was used")))
>   (#t #f))
>
> and likewise for the "guix home" equivalent, such that if user configurations
> are used in the system configuration, an error message is printed, indicating
> the issue?  Maybe include the line and column number of the record as well.
>
> Greetiings,
> Maxime.

Hi Maxime,

Nice idea and viable solution, but here I was talking about the case,
when both home-mcron-service-type and mcron-service-type in the same
(gnu services mcron) namespace.  I expect much less confusion and it
probably won't be an issue, when they are in different modules (gnu
home-services mcron) and (gnu services mcron) for example.  If person
imports (gnu services SOMETHING) than they expect to get system services
for their operating-system, if they imports (gnu home-services
SOMETHING) they want to extend their home-environment. 


signature.asc
Description: PGP signature

On the naming of System and Home services modules.

[Andrew Tropin]

This topic was raised a few times during development of Guix Home
project and also during the review of wip-guix-home branch.  I made a
separate thread to do an exhaustive discussion of it.

* Services and Confusion
It's an optional section, you can skip it, but I still find it somehow
related to the topic.

I want to re-raise the issue related to system services concept.  When
I started using Guix I found system services to be confusing,
originally I thought it's a way to declare services managed by init
system, but later I realised that only some of system services becomes
Shepherd services and many of them doesn't.  It's not a unique problem
I see this issue appear again and again in different Guix chats and
communities.

- System services :: just building blocks, nodes of DAG representing
a system, which after folding, results in a complete operating system
or other artifact.
- Shepherd services :: long-living processes/daemons managed by init
system or user-space Shepherd. It's what people used to refer as services.

It will be very hard and costly to rename system services to something
less confusing, but at least let's try to keep those concepts as
distinct as possible.  Probably originally system and Shepherd
services were closely related, but not now, so let's express it very
clearly in docs/chats/mailing lists.

Another player on this field is "home services", which is a similar to
system services, but used for describing a separate DAG, which after
folding, results in home environment (artifact containing user's
program configurations and profile with packages declared by user).

* Putting Home Services to ~(gnu services ...)~
In the thread https://issues.guix.gnu.org/49419#18 Ludovic suggested:

> Regarding module names: what about putting everything in the (gnu
> home …) name space.  For services, I wonder if we could simply use
> (gnu services home), for the essential services, and other (gnu
> services …) module, but that assumes some code can be shared between
> System and Home.  Thoughts?

** Shortcomings
While it's a nice idea, I see some shortcomings here:

*** Code Reuse
Mcron, Shepherd and a few other fundamental pieces are reused between
Guix Home and Guix System, but it's easily done by exporting a few
symbols from related modules.

Records even for the same services have slightly different fields and
because of macro nature can't be reused between Home and System
services. In more details I mentioned this problem here:
https://lists.sr.ht/~abcdw/rde-devel/%3C87y2cqifpx.fsf%40yoctocell.xyz%3E#%3c878s4l8kai@trop.in%3E

The intersection of home and system services should be very low, so
there is not much benifit here as well.

Utilitary functions like serialization helpers and so on can be
declared in a shared module and reused between System and Home
services.

Recaping the section: All the necessarry code already reused, the
future home/system services are not expected to share much code,
different utilitary functions can be shared via (gnu services utils)
or (gnu services configuration) modules.

*** Confusion
I already mentioned that I see a lot of confusion between System and
Shepherd services and I expect some confusion between home and system
services, it will be especially true if we place them in the same
namespace.

People will be trying to use home services inside operating systems,
#+begin_src scheme
(operating-system
  (services
   (list (service home-mcron-service-type ...
#+end_src

and configuration record for system services inside home services.
#+begin_src scheme
(home-environment
 ... (service home-mcron-service-type
  (mcron-configuration ...)))
#+end_src

** Summary
Let's keep System and Home services separate for the sake of clarity,
reuse code via shared modules or just exports in (gnu services ...).

* Putting Home Services to ~(gnu home services ...)~
Another idea I saw is to move:
~(gnu home-services)~ -> ~(gnu home services)~
~(gnu home-services gnupg)~ -> ~(gnu home services gnupg)~
...

Sounds reasonable, I'll just mention the ideas behind ~home-services~
name.

System services have following naming conventions for the public API:

in ~(gnu services CATEGORY)~ there are ~APP-service-type~,
~APP-configuration~ and other related symbols.

Not to be confused, I decided to prefix all service types and
configurations with ~home-~, so the exported symbols looks like:
~home-APP-service-type~ and ~home-APP-configuration~.

The same rule applies for module names: We do the same way as system
services do, but with ~home-~ prefix: ~(gnu services CATEGORY)~ for
system, ~(gnu home-services CATEGORY)~ for home.

All namespaces containing ~system~ now becomes ~home~: ~(gnu system)~ and
~(gnu home)~ respectively.

I find such approach to be consistent and doesn't see to much reasons
to change it.

However, ~(gnu home services ...)~ also looks cool, but it would be a
little inconsistent with system services, which will have one level of
nestiness less: 

Re: Guix Home is coming in the next Guix release

[Andrew Tropin]

Maxim Cournoyer  writes:

> Hi Andrew,
>
> Andrew Tropin  writes:
>
>> We started cleaning up and moving Guix Home from rde repository to Guix
>> proper.  It's expected to be included in the next release.
>>
>> For people not yet familiar with it: Guix Home is a tool for managing
>> home envirnoment (dotfiles, user's Guix profile and user's Shepherd
>> services) in a declarative way, very similar to how Guix System manages
>> operating system.
>>
>> The repository and documentation are available here:
>> https://sr.ht/~abcdw/rde
>> https://guix-home.trop.in/Home-Configuration.html
>>
>> The project is under active refactoring, so the docs can be slightly
>> outdated.
>>
>> If you already use it, don't hesitate to provide your feedback.
>>
>> Have a great weekend and expect to be able to run
>> `guix home reconfigure` in the foreseeable future!)
>
> Exciting!  I've glossed at yoctocell's configuration, and I'm thrilled
> that I'll have something higher level to manage my software
> configuration soon :-).
>
> Thank you for working on it.

;-)


signature.asc
Description: PGP signature

Re: Early feedback on Guix Home

[Andrew Tropin]

Ludovic Courtès  writes:

> Hi,
>
> (Sorry for the late reply…)
>
> Andrew Tropin  skribis:
>
>> Ludovic Courtès  writes:
>
> [...]
>
>>>>> Possible action:
>>>>>
>>>>>   1. Change config records to accept file-like objects instead of
>>>>>  strings.  That way, users can choose to have snippets inlined (in a
>>>>>  ‘plain-file’ object) or separate (via ‘local-file’).  See for
>>>>>  example how ‘tor-configuration->torrc’ does it.
>>>>
>>>> Yeah, there is a ‘slurp-file-gexp’ procedure that let’s one read an
>>>> extenal file, but using existing APIs like ‘local-file’ is probably a
>>>> better idea.
>>>
>>> Yes, it feels more natural.  Also, ‘slurp-file-gexp’ returns a gexp (a
>>> code snippet), but as a user you don’t know where that snippet is going
>>> to be inserted; it may not work in some contexts.
>>
>> Acually, the idea behind `slurp-file-gexp` is that you always know where
>> it will be inserted, because it will be inside the specific section of
>> the configuration.  Take a look at emacs home-service example:
>> https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services/emacs.scm#L91
>
> What I mean is that, in a general sense, one cannot know whether the
> gexp will be inserted in a place where it’s “valid”.  Consider the
> following examples, where the gexp is meant to be inserted in lieu of
> “PLACEHOLDER”:
>
>   #~(list '(#$PLACEHOLDER))  ;it’s quoted
>
>   #~(let ((call-with-input-file (const #f)))
>   #$PLACEHOLDER)
>
> These are “hygiene” problems discussed in the “Code Staging in GNU Guix”
> paper.
>
> All this to say that, from an API viewpoint, I think it’s (1) more
> robust, as I wrote, and (2) clearer to expect file-like objects in such
> places.  It’s clearer because users can be expected to have an
> understanding of what ‘local-file’ does, whereas ‘slurp-file-gexp’ is
> more involved.
>
> I hope this clarifies what I had in mind!
>
> Ludo’.

Got the problem.  Will take a closer look, when will be preparing this
code for upstreaming and maybe will reconsider the approach or will rise
another discussion on that.  Also, need to schedule a reading of your
paper on gexps)

Thank you for clarification!)


signature.asc
Description: PGP signature

Re: Guix Home is coming in the next Guix release

[Andrew Tropin]

Chris Lemmer-Webber  writes:

> Wow, this is really exciting!
>
> May I ask, is this limited to on a per-user basis?  Is it also possible
> to, say, launch shepherds which launch shepherds?

Not sure what you mean here)  If you can elaborate on the use case, I'll
provide more detailed answer)

> Even if not, this is a massive step forward, just wondering :)


signature.asc
Description: PGP signature

Guix Home is coming in the next Guix release

[Andrew Tropin]

We started cleaning up and moving Guix Home from rde repository to Guix
proper.  It's expected to be included in the next release.

For people not yet familiar with it: Guix Home is a tool for managing
home envirnoment (dotfiles, user's Guix profile and user's Shepherd
services) in a declarative way, very similar to how Guix System manages
operating system.

The repository and documentation are available here:
https://sr.ht/~abcdw/rde
https://guix-home.trop.in/Home-Configuration.html

The project is under active refactoring, so the docs can be slightly
outdated.

If you already use it, don't hesitate to provide your feedback.

Have a great weekend and expect to be able to run
`guix home reconfigure` in the foreseeable future!)

--
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Guix Home is coming in the next Guix release

[Andrew Tropin]

We started cleaning up and moving Guix Home from rde repository to Guix
proper.  It's expected to be included in the next release.

For people not yet familiar with it: Guix Home is a tool for managing
home envirnoment (dotfiles, user's Guix profile and user's Shepherd
services) in a declarative way, very similar to how Guix System manages
operating system.

The repository and documentation are available here:
https://sr.ht/~abcdw/rde
https://guix-home.trop.in/Home-Configuration.html

The project is under active refactoring, so the docs can be slightly
outdated.

If you already use it, don't hesitate to provide your feedback.

Have a great weekend and expect to be able to run
`guix home reconfigure` in the foreseeable future!)

--
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

Re: Early feedback on Guix Home

[Andrew Tropin]

Ludovic Courtès  writes:

> Hi,
>
> Xinglu Chen  skribis:
>
>> On Wed, Jun 23 2021, Ludovic Courtès wrote:
>
> [...]
>
>>> Anyway, I backed up a bunch of files :-) and eventually gave it a try,
>>> just to notice that ‘guix home reconfigure’ was very careful about
>>> creating backups of any files it was going to overwrite, and it was also
>>> explicitly saying what it’s doing.  Perfect.
>>
>> Yeah, the output is pretty verbose, which is good if someone is just
>> getting started with it, but there should probably also be an option to
>> make it less verbose.
>
> Yes.  Also, we’ll have to make sure it’s internationalized.
>
>>> I see two possible improvements:
>>>
>>>   1. Make the manual very upfront about that: don’t be afraid, config
>>>  files are backed up at that location, etc.
>>
>> Yeah, the manual needs some more work, maybe we should add an ‘migrating
>> to Guix Home’ section?
>
> That’s a good idea.
>
>>>   2. Review ‘symlink-manager.scm’ and work on simplifying it to make it
>>>  easier to understand what’s going on.
>>>
>>> Second, the other thing that stopped me from getting started is the
>>> initial config.  How could I move from all my undisciplined dotfiles to
>>> the single explicit config?  Eventually, I found that starting with
>>> nothing but packages, ‘home-bash-service-type’, and
>>> ‘home-ssh-service-type’ was the most reasonable option to begin with.
>>>
>>> Unfortunately, even ‘home-ssh-service-type’ was difficult to handle: I
>>> have a long ‘.ssh/config’ file and I wasn’t going to turn that into
>>> ‘ssh-host’ lines by hand.
>>
>> There is a ‘home-generic-service’ procedure that allows one to install
>> packages in dump a file somewhere in their home directory.
>>
>>   (home-generic-service
>>'ssh-config
>>#:packages (list openssh)
>>#:files `(("ssh/config"
>>   ,(local-file "/path/to/some/ssh/config"
>
> Neat.
>
>>> Possible actions:
>>>
>>>   1. Provide a ‘guix home init’ command (or similar) that creates an
>>>  initial Home config based on existing config.
>>
>> As Andrew mentioned, I recently added a ‘guix home import’ command, but
>> in only imports the installed user packages.  Creating configurations
>> for the packages would require a lot more work, unless we just read the
>> contents of ~/.bashrc and ~/.config/git/config and use
>> ‘home-generic-service’ and ‘plain-file’, instead of using
>> ‘home-bash-configuration’ and ‘home-git-configuration’.
>
> For SSH, generating something like:
>
>(service home-ssh-service-type
> (home-ssh-configuration
>  (toplevel-options
>   `((include . ,(local-file "ssh.conf"))
>
> should be doable.  But yeah, we’ll have to see on a case-by-case basis
> what can be achieved.
>
>>>   2. In some cases, such as OpenSSH, provide converters from the native
>>>  format to its Scheme equivalent (maybe?).
>>
>> That would require a lot of work; we would have to parse all sorts of
>> weird configuration formats, not to mention that the upstream
>> configuration format can change in the future.  It would be nice to
>> have, but I don’t think it should be a blocker for merging Guix Home.
>
> Agreed.
>
>>>   3. For each service, provide an escape hatch: a way for users to
>>>  provide a raw config file.  We do that for all or most of the Guix
>>>  System services, and it helps a lot when people are starting from
>>>  an existing config.
>>
>> Since we already have the ‘home-generic-service’ helper, I am not sure
>> if explicitly providing an escape hatch for every single service is
>> worth it.  I feel like the point is to use Scheme to configure things,
>> and not to just concatenate big opaque strings.  People who haven’t
>> re-written their configs in Scheme can always use
>> ‘home-generic-service’.  ‘home-generic-service’ is also useful if say
>> the user wants to configure Mpv, but there is no Mpv service in Guix
>> Home.
>
> Yeah, ‘home-generic-service’ helps a lot, I didn’t know about it.

Will mention it in the manual.

> Overall, I think what I’m saying is that we should offer a smooth and
> gradual transition for enthusiasts (like me!) who’re willing to switch
> but can’t just be expected to rewrite all their config at once.
>
>>> Possible action:
>>>
>>>   1. Change config records to accept file-like objects instead of
>>>  strings.  That way, users can choose to have snippets inlined (in a
>>>  ‘plain-file’ object) or separate (via ‘local-file’).  See for
>>>  example how ‘tor-configuration->torrc’ does it.
>>
>> Yeah, there is a ‘slurp-file-gexp’ procedure that let’s one read an
>> extenal file, but using existing APIs like ‘local-file’ is probably a
>> better idea.
>
> Yes, it feels more natural.  Also, ‘slurp-file-gexp’ returns a gexp (a
> code snippet), but as a user you don’t know where that snippet is going
> to be inserted; it may not work in some contexts.

Acually, the idea behind `slurp-file-gexp` is that you always 

Re: Early feedback on Guix Home and a basic almost complete sway service

[Andrew Tropin]

Joshua Branson  writes:

> Thanks for the help in my home.scm file by the way!  I figured since you
> guys are writing a sway service, I'd share with you my current code for
> a sway service.  I think I've got the records type flushed out enough to
> build the default sway config file, but I have not finished turning it
> into a proper service.  Anyway, here's the code if you are interested:
>
> https://notabug.org/jbranso/guix-config/src/master/sway-service.scm

Very cool!  Checked the source code briefly, I'll add the link to your
implementation to the Guix Home's source code and will revisit it before
sending sway home-service patch to guix.

Re: Early feedback on Guix Home

[Andrew Tropin]

Joshua Branson  writes:

> Andrew Tropin  writes:
>
>> jbra...@dismail.de writes:
>>> $ guix pull
>>>
>>> I suppose for now I will use Ludo's suggestion:
>>>
>>>   git clone https://git.sr.ht/~abcdw/rde
>>>   guix git authenticate \
>>> "257cebd587b66e4d865b3537a9a88cccd7107c95" \
>>> "2841 9AC6 5038 7440 C7E9  2FFA 2208 D209 58C1 DEB0" \
>>> -k origin/keyring
>>>   ./pre-inst-env guix home reconfigure /path/to/home-config.scm
>>>
>>> Failed to execute process './pre-inst-env'. Reason:
>>> exec: Exec format error
>>> The file './pre-inst-env' is marked as an executable but could not be run 
>>> by the operating system.
>>
>> It should work if you have a POSIX-compatible shell, but I also added
>> shebang to be sure that /bin/sh used.  Do git pull inside repository dir
>> and try again.  `./pre-inst-env guix home --help`
>>
>> Let me know if it still fails.
>
> Totally works now.  I was using the fish shell...and I don't believe
> the fish shell is a POSIX compatible shell.  :) Works fine in bash.
>
> Also thanks for the tips in my initial config!
>
> And I really like the home-keyboard-service-type,
> home-files-service-type, and home-state-service-type!

I do care about multi-input-method setups, so it is one of the earliest
home services, also in rde features I provide emacs-input-method
feature, which I find quite useful too:
https://git.sr.ht/~abcdw/rde/tree/262c7fb2db7454fdf4f67bbc53ec0c0306a8fbaf/item/rde/features/emacs.scm#L238

> I've got a lot of
> git repos.  It takes me forever to clone those.  Do you know if
> home-state-service type will help me to automate something like
>
> Git repo "programming" goes here:  /home/joshua/prog/
>
> and git repo "cheatsheets" goes here: /home/joshua/prog/cheatsheets/
>
> and git repo "guix-config" goes here: /home/joshua/prog/gnu/guix/guix-config/
>
> and git repo "guix-src" goes here: /home/joshua/prog/gnu/guix/guix-src/
>
> and git repo "guile" goes here: /home/joshua/prog/guile/
>
> and git repr "gnucode.me" goes here: /home/joshua/prog/guile/gnucode.me

Yes, home-state-service perfectly covers this use case, however I do not
recommend to use it, because probably I'll refactor it quite hard sooner
or later.  For now you can consider it to be in alpha state.  Usage
example is here:
https://git.sr.ht/~abcdw/rde/tree/262c7fb2db7454fdf4f67bbc53ec0c0306a8fbaf/item/rde/config.scm#L436

>
> I don't that you are curious, but if you are my git repos are on
> notabug.org/jbranso.

Probably I need to add Guix Home configs collection section to rde repo
README to make it easier for people to explore other's configurations)

> Thanks!  And thanks so much for working on this!  And thanks to Ludo for
> testing it!
>
> --
> Joshua Branson (joshuaBPMan in #guix)
> Sent from Emacs and Gnus
>   https://gnucode.me
>   https://video.hardlimit.com/accounts/joshua_branson/video-channels
>   https://propernaming.org
>   "You can have whatever you want, as long as you help
> enough other people get what they want." - Zig Ziglar

Re: Early feedback on Guix Home

[Andrew Tropin]

Leo Prikler  writes:

> Am Donnerstag, den 24.06.2021, 20:42 +0300 schrieb Andrew Tropin:
>> It should be `guix home build ./path/to/file.scm`.  Also, make sure
>> that
>> before first run you've set proper GUILE_LOAD_PATH. (See
>> https://sr.ht/~abcdw/rde/ Guix Home section, Option 2).
>> 
>> It won't be needed, when Guix Home will be upstreamed, but for now it
>> is
>> necessary, if you want to use it from rde channel.
> This probably comes a little late, but have you considered writing a
> small wrapper module, that sets up %load-path and calls guix-home
> proper?  The Guix package is set up to locate extensions from
> share/guix/extensions.  I haven't checked if that works for channels,
> but you ought to give it a try.

IIRC, Jelle Licht proposed the usage of guix extensions some time ago,
but I decided not to provide such capability.

https://lists.sr.ht/~abcdw/rde-devel/patches/22245

But thank you for reminding, maybe I'll revisit guix extensions in the
future!)

Re: Early feedback on Guix Home

[Andrew Tropin]

jbra...@dismail.de writes:

> June 24, 2021 8:14 AM, "Xinglu Chen"  wrote:
>
>> On Wed, Jun 23 2021, Ludovic Courtès wrote:
>> 
>> Alternatively, one can also use it as a channel:
>> 
>> (channel
>> (name 'rde)
>> (url "https://git.sr.ht/~abcdw/rde;))
>> (introduction
>> (make-channel-introduction
>> "257cebd587b66e4d865b3537a9a88cccd7107c95"
>> (openpgp-fingerprint
>> "2841 9AC6 5038 7440 C7E9 2FFA 2208 D209 58C1 DEB0"
>
> Maybe I'm doing it wrong...my ~/.config/guix/channels.scm
>
> ;; Add variant packages to those Guix provides.
> (append
> (list
> (channel
> (name 'guix-packages)
> (url "https://notabug.org/jbranso/guix-packages;))
> (channel
> (name 'rde)
> (url "https://git.sr.ht/~abcdw/rde;)
> (introduction
> (make-channel-introduction
> "257cebd587b66e4d865b3537a9a88cccd7107c95"
> (openpgp-fingerprint
> "2841 9AC6 5038 7440 C7E9 2FFA 2208 D209 58C1 DEB0")
> %default-channels)
>
> $ guix pull
> Updating channel 'guix-packages' from Git repository at
> 'https://notabug.org/jbranso/guix-packages'...
> Updating channel 'rde' from Git repository at 
> 'https://git.sr.ht/~abcdw/rde'...
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Authenticating channel 'guix', commits 9edb3f6 to 8553f00 (3 new commits)...
> Building from these channels:
> guix https://git.savannah.gnu.org/git/guix.git 8553f00
> rde https://git.sr.ht/~abcdw/rde 6d32c23
> guix-packageshttps://notabug.org/jbranso/guix-packages d4b6f35
>
> $ guix build home.scm

It should be `guix home build ./path/to/file.scm`.  Also, make sure that
before first run you've set proper GUILE_LOAD_PATH. (See
https://sr.ht/~abcdw/rde/ Guix Home section, Option 2).

It won't be needed, when Guix Home will be upstreamed, but for now it is
necessary, if you want to use it from rde channel.

> $ guix pull
>
> I suppose for now I will use Ludo's suggestion:
>
>   git clone https://git.sr.ht/~abcdw/rde
>   guix git authenticate \
> "257cebd587b66e4d865b3537a9a88cccd7107c95" \
> "2841 9AC6 5038 7440 C7E9  2FFA 2208 D209 58C1 DEB0" \
> -k origin/keyring
>   ./pre-inst-env guix home reconfigure /path/to/home-config.scm
>
> Failed to execute process './pre-inst-env'. Reason:
> exec: Exec format error
> The file './pre-inst-env' is marked as an executable but could not be run by 
> the operating system.

It should work if you have a POSIX-compatible shell, but I also added
shebang to be sure that /bin/sh used.  Do git pull inside repository dir
and try again.  `./pre-inst-env guix home --help`

Let me know if it still fails.

>
> Eventually I'll be able to get it to work!  But I do like the concept!
>
> #+BEGIN_SRC scheme
> (use-modules (gnu home)
>(gnu home-services)
>(gnu home-services ssh)
>(gnu home-services shells)
>(gnu home-services files)
>(gnu services)
>(gnu packages admin)
>  (guix gexp)
>  (my-home packages) ;; %defines %my-packages
>  )
>
>
> (home-environment
>  (home-directory "/home/joshua")

home-directory, as well as symlink-name and symlink-path are now
depricated, I'll update the manual soon.

>  ;; (symlink-name ".guix-home-env")
>  (packages %my-packages)
>  (services
>   (list
>(service home-bash-service-type
> (home-bash-configuration
>  (guix-defaults? #t)
>  (bash-profile '("\ export 
> HISTFILE=$XDG_CACHE_HOME/.bash_history;\n"
>  "if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty3 
> ]]; then\n"
>  "# this may fix a bug that I have with termite 
> confusing backspace as space in guix environment\n"
>  "# export TERM=linux\n"
>  "# shepherd -c 
> /home/joshua/.config/shepherd/init.scm &\n"
>  "export MOZ_ENABLE_WAYLAND=1;\n"
>  "export 
> GUIX_PACKAGE_PATH=/home/joshua/prog/gnu/guix/guix-packages/;\n"
>  "export 
> XDG_DATA_DIRS=/var/lib/flatpak/exports/share:/home/joshua/.local/share/flatpak/exports/share:$XDG_DATA_DIRS;\n"
>  "exec dbus-run-session sway;\n"
>  "fi"
>  ))
>  (bashrc
>   '("alias lamora='ssh -p 63355 lamora'"
>
>(simple-service 'termite-config
>home-files-service-type
>(list `("config/termite/config"
>,(local-file "config-files/termite-config"
> "config"
>
>(simple-service 'sway-config
>home-files-service-type
>(list `("config/sway/config"
>,(local-file "config-files/sway-config"
> "config"
>
>(simple-service 'sway-config
>home-files-service-type
> 

Re: Early feedback on Guix Home

[Andrew Tropin]

Xinglu Chen  writes:

> On Wed, Jun 23 2021, Ludovic Courtès wrote:
>
>> Hello!
>>
>> As discussed on IRC a few days ago, I finally gave Guix Home a try and I
>> like it!
>>
>> I thought I’d share my first impressions so we can try and address them
>> in the process of getting it merged.
>>
>> First, I think one of the main reasons why it took me so long to try it
>> out is that I was afraid of what would happen at “activation time” (upon
>> reconfigure).  Were my dot files going to be deleted?  If so, which ones
>> exactly should I back up?  That led me to look more closely at the code
>> to better understand what was going to happen.  I found
>> ‘symlink-manager.scm’, which is what I was looking for, but that code is
>> fairly complex.
>>
>> Anyway, I backed up a bunch of files :-) and eventually gave it a try,
>> just to notice that ‘guix home reconfigure’ was very careful about
>> creating backups of any files it was going to overwrite, and it was also
>> explicitly saying what it’s doing.  Perfect.
>
> Yeah, the output is pretty verbose, which is good if someone is just
> getting started with it, but there should probably also be an option to
> make it less verbose.
>
>> I see two possible improvements:
>>
>>   1. Make the manual very upfront about that: don’t be afraid, config
>>  files are backed up at that location, etc.
>
> Yeah, the manual needs some more work, maybe we should add an ‘migrating
> to Guix Home’ section?

Yup, on my todo list.

>>   2. Review ‘symlink-manager.scm’ and work on simplifying it to make it
>>  easier to understand what’s going on.
>>
>> Second, the other thing that stopped me from getting started is the
>> initial config.  How could I move from all my undisciplined dotfiles to
>> the single explicit config?  Eventually, I found that starting with
>> nothing but packages, ‘home-bash-service-type’, and
>> ‘home-ssh-service-type’ was the most reasonable option to begin with.
>>
>> Unfortunately, even ‘home-ssh-service-type’ was difficult to handle: I
>> have a long ‘.ssh/config’ file and I wasn’t going to turn that into
>> ‘ssh-host’ lines by hand.
>
> There is a ‘home-generic-service’ procedure that allows one to install
> packages in dump a file somewhere in their home directory.
>
>   (home-generic-service
>'ssh-config
>#:packages (list openssh)
>#:files `(("ssh/config"
>   ,(local-file "/path/to/some/ssh/config"
>
>> Possible actions:
>>
>>   1. Provide a ‘guix home init’ command (or similar) that creates an
>>  initial Home config based on existing config.
>
> As Andrew mentioned, I recently added a ‘guix home import’ command, but
> in only imports the installed user packages.  Creating configurations
> for the packages would require a lot more work, unless we just read the
> contents of ~/.bashrc and ~/.config/git/config and use
> ‘home-generic-service’ and ‘plain-file’, instead of using
> ‘home-bash-configuration’ and ‘home-git-configuration’.
>
>>   2. In some cases, such as OpenSSH, provide converters from the native
>>  format to its Scheme equivalent (maybe?).
>
> That would require a lot of work; we would have to parse all sorts of
> weird configuration formats, not to mention that the upstream
> configuration format can change in the future.  It would be nice to
> have, but I don’t think it should be a blocker for merging Guix Home.
>
>>   3. For each service, provide an escape hatch: a way for users to
>>  provide a raw config file.  We do that for all or most of the Guix
>>  System services, and it helps a lot when people are starting from
>>  an existing config.
>
> Since we already have the ‘home-generic-service’ helper, I am not sure
> if explicitly providing an escape hatch for every single service is
> worth it.  I feel like the point is to use Scheme to configure things,
> and not to just concatenate big opaque strings.  People who haven’t
> re-written their configs in Scheme can always use
> ‘home-generic-service’.  ‘home-generic-service’ is also useful if say
> the user wants to configure Mpv, but there is no Mpv service in Guix
> Home.

In most cases we allows gexps or/and file-like objects (with
`local-file` and include/load or similar directive provided by target
software it's easy to include/source already existing file), so it's
almost always a way to take current plain-text file configuration and
include or slurp it into configuration home-service.  In other words,
there is already an escape hatch for almost every home-service.

>> In terms of API, I noticed that in places such as
>> ‘home-bash-configuration’, config snippets are represented as a list of
>> strings (internally passed to ‘mixed-text-file’).  That forces users to
>> mix different languages in their .scm file—e.g., half of my Home config
>> is .bash{rc,_profile} snippets embedded in Scheme strings.  That’s
>> inconvenient.
>>
>> Possible action:
>>
>>   1. Change config records to accept file-like objects instead of
>>  

Re: Early feedback on Guix Home

[Andrew Tropin]

Ludovic Courtès  writes:

> Hello!
>
> As discussed on IRC a few days ago, I finally gave Guix Home a try and I
> like it!
>
> I thought I’d share my first impressions so we can try and address them
> in the process of getting it merged.
>
> First, I think one of the main reasons why it took me so long to try it
> out is that I was afraid of what would happen at “activation time” (upon
> reconfigure).  Were my dot files going to be deleted?  If so, which ones
> exactly should I back up?  That led me to look more closely at the code
> to better understand what was going to happen.

Good to know, added a todo to make it clearer in the documentation.

> I found ‘symlink-manager.scm’, which is what I was looking for, but
> that code is fairly complex.

Yep, perhaps it a little monstous)  Maybe cleaning it up is a good idea
before sending the patch to guix.

> Anyway, I backed up a bunch of files :-) and eventually gave it a try,
> just to notice that ‘guix home reconfigure’ was very careful about
> creating backups of any files it was going to overwrite, and it was also
> explicitly saying what it’s doing.  Perfect.
>
> I see two possible improvements:
>
>   1. Make the manual very upfront about that: don’t be afraid, config
>  files are backed up at that location, etc.
>
>   2. Review ‘symlink-manager.scm’ and work on simplifying it to make it
>  easier to understand what’s going on.

Sounds reasonable)

> Second, the other thing that stopped me from getting started is the
> initial config.  How could I move from all my undisciplined dotfiles to
> the single explicit config?  Eventually, I found that starting with
> nothing but packages, ‘home-bash-service-type’, and
> ‘home-ssh-service-type’ was the most reasonable option to begin with.
>
> Unfortunately, even ‘home-ssh-service-type’ was difficult to handle: I
> have a long ‘.ssh/config’ file and I wasn’t going to turn that into
> ‘ssh-host’ lines by hand.
>
> Possible actions:
>
>   1. Provide a ‘guix home init’ command (or similar) that creates an
>  initial Home config based on existing config.

Xinglu implemented `guix home import`, which creates a simple
home-environment configuration, which contains the same packages as 
~/.guix-profile

>   2. In some cases, such as OpenSSH, provide converters from the native
>  format to its Scheme equivalent (maybe?).

It's a good idea and Xinglu also mentioned it, but I find it to be a lot
of extra work, so I propose to postpone it until next time, IMO it's
better to focus on moving Guix Home from rde repo first in the current
state and add new functionality after that step is done, otherwise we
can stuck with wip-guix-home for months.

>   3. For each service, provide an escape hatch: a way for users to
>  provide a raw config file.  We do that for all or most of the Guix
>  System services, and it helps a lot when people are starting from
>  an existing config.

We do it as well, the only difference is that we try to utilize target
program capabilities or slurp-file-gexp helper for that.

The first one means that target configuration format allows to use some
directive to load the content of another file:
https://git.sr.ht/~abcdw/rde/tree/master/gnu/home-services/ssh.scm#L190
https://git.sr.ht/~abcdw/rde/tree/master/gnu/home-services/emacs.scm#L200

The second one inlines the content of file directly in configuration.
In most cases it's done by providing a gexp, which reads the content of
the file in the store and returning its content as a string to make
mixed-text-file to add it to the target configuration.
https://git.sr.ht/~abcdw/rde/tree/master/gnu/home-services/emacs.scm#L208

> In terms of API, I noticed that in places such as
> ‘home-bash-configuration’, config snippets are represented as a list of
> strings (internally passed to ‘mixed-text-file’).  That forces users to
> mix different languages in their .scm file—e.g., half of my Home config
> is .bash{rc,_profile} snippets embedded in Scheme strings.  That’s
> inconvenient.

Can you elaborate on that please, ideally with some examples.

> Possible action:
>
>   1. Change config records to accept file-like objects instead of
>  strings.  That way, users can choose to have snippets inlined (in a
>  ‘plain-file’ object) or separate (via ‘local-file’).  See for
>  example how ‘tor-configuration->torrc’ does it.
>
> That’s it.  I hope it makes sense to you!

Make a lot of sense, thank you for the feedback and suggestions!)

> I encourage everyone to give it a spin, fearlessly!
> What I did was (roughly):
>
>   git clone https://git.sr.ht/~abcdw/rde
>   guix git authenticate \
> "257cebd587b66e4d865b3537a9a88cccd7107c95" \
> "2841 9AC6 5038 7440 C7E9  2FFA 2208 D209 58C1 DEB0" \
> -k origin/keyring

And to get the initial configuration, it's a good idea to take a look at
gnu/home/examples directory or call import action:

   ./pre-inst-env guix home import > /path/to/home-config.scm

>   ./pre-inst-env 

Re: Guix Home upstreaming plan

[Andrew Tropin]

Xinglu Chen  wrote:

> WDYT Andrew?

As I said, a few months should be enough, but I hope we will accomplish
it faster)

Re: Guix Home upstreaming plan

[Andrew Tropin]

Hi Ludovic, 

Ludovic Courtès  wrote:

> So, I have yet to go ahead and use it for myself to get a better feel.
> In the meantime, I looked at
> , and I like what I
> see!  It’s great that you already have clear documentation and that
> everything looks consistent with the rest of Guix.

> Since this kind of tool is rather unusual (there’s no real equivalent
> I’m aware of in other distros), I think the manual will have to
> carefully explain what problems this solves and explain why someone
> would want to use it.  For example, I think the term “home environment”
> should be defined upfront (I’d summarize it as user configuration files
> + user services, from my reading.)

Sounds reasonable, added a TODO note for that.

> I’m all for it.  We’ll have to discuss it together, in particular among
> maintainers, but an option would be to give you commit access for the
> purposes of developing this branch.

Sound good to me.  We still have some work to be finished before
upstreaming, but hope we will be good to go by the time other
maintainers will reply.

> I would also like to know what Julien thinks; I think it’s in our
> interest to see cooperation and not competition between the two
> approaches you developed.  Julien, WDYT of the plan?  More specifically,
> is there anything about the design that you’d like to discuss before we
> go further?  Are there guix-home-manager features that could eventually
> make it in Guix Home?

BTW, from time to time people ask about read-only home feature) I reply
that it is theoretically possible, but probably won't be implemented
anytime soon.

> I find the steady progress on Guix Home and the level of polish already
> achieved pretty exciting.  If people agree, I think we could aim for
> merging it in the next Guix release, which would leave us a few months.

Thank you for kind words!)  A few months should be enough.  Looking
forward to see other maintainers thoughts.

> Thank you!

Sure!

Guix Home upstreaming plan

[Andrew Tropin]

There is a goal[0] to make Guix Home[1] a part of GNU Guix.  It will reduce
the duplications between projects, increase integrity and will provide
Guix users with a missing tool for declarative configuration of home
environments improving out of the box experience and allowing Guix users
on foreign distros to have Guix System-like experience.

The outline of before upstreaming checklist looks like:
* [done]Implement a `guix home` utility and essential services.
* [in-progress] Implement a complete home environment with it [2].
* [in-progress] Run Early Adopters program, gather feedback.
* [done]Write documentation [3].
* [in-progress] Generate documentation for each home service.
* [in-progress] Test a complete home environment on foreign distro.
* [todo]Add tests for complex serializers and essential functions.

I don't expect upstreaming process to be fast, it will require a lot of
time for review and probably changes after review and it seems logical
to start it early, even before checklist is complete.  Also, I don't
want to replicate documenting and testing infrastracture and that is why
we will be adding docs and tests directly to guix repo (for now it's [4]),
while moving the code from rde project.

We still cleaning up things, but I hope that we can start sending
patches in a week or two.  I expect it to be a few patch series.

civodul, can we create a separate guix-home branch to work against it?

Dear Maintainers, please, let me know what you think.


[0]: https://lists.gnu.org/archive/html/guix-devel/2021-03/msg00167.html

[1]: https://sr.ht/~abcdw/rde

[2]: Complete home environment in this context is a configured and
integrated minimalistic set of apps: window manager/compositor, text
editor, vcs, mail client, web browser, key and password managers, shell.

[3]: https://guix-home.trop.in/Home-Configuration.html#Home-Configuration

[4]: https://git.sr.ht/~abcdw/guix

--
Best regards,
Andrew Tropin

Re: guix home: Call for Early Adopters

[Andrew Tropin]

> Could you sign your rde channel? I am not at ease adding unsigned
> channels since that's basically RCE into my system :-)

It is not intended for use as a channel, at least yet, because
`guix home` will not work without:

export 
GUILE_LOAD_PATH=~/.config/guix/current/share/guile/site/3.0:$GUILE_LOAD_PATH
export 
GUILE_LOAD_COMPILED_PATH=~/.config/guix/current/lib/guile/3.0/site-ccache:$GUILE_LOAD_COMPILED_PATH

By "local checkout of the rde Git repository", I meant literal
`git clone` to the local file system)

Anyway, I signed the channel,  the introduction is in the README.  Maybe
later I'll write a guide explaining how to use it as a channel.

> Thanks!!

You are very welcome (: and thank you for motivating me to clean up and
improve things)

guix home: Call for Early Adopters

[Andrew Tropin]

Guix Home has most essential features ready and now requires some
real-world usage from a few more people to be sure that there are no
fundamental issues with it.

We are looking for 3-5 advanced GNU/Linux users (not necessary Guix),
who want to try `guix home` and are willing to spend some time and
effort configuring it, and in case of issues reporting them to
https://lists.sr.ht/~abcdw/rde-discuss

We will be supporting early adopters in the rde-discuss mailing list on
weekdays.  Also, you can reach us on #guix IRC channel for a casual talk
or quick question, @abcdw and @yoctocell.

On `date --date="2021-04-14 15:00:00 UTC"` we plan a jitsi call, to
make sure that everyone is up and running, provide some help and/or
answer questions.  Will schedule consequent calls if needed.

To participate you need to have a working installation of Guix the
package manager, and have a local checkout of the rde Git
repository[1].  Reply to the thread in rde-discuss [2] with a few
lines about you and/or your technical background and please attach the
output of running `make env-info` at the root of the rde repository to
be sure that Guix and rde are installed and everything works correctly.

See you soon,
Andrew Tropin.

Useful links:
[1] https://git.sr.ht/~abcdw/rde
[2] https://lists.sr.ht/~abcdw/rde-discuss

Re: guix home

[Andrew Tropin]

Hi Julien, very glad to see you here!)

> Obviously I'm not a big fan of having configuration that can be modified
> after I ran guix home, but I understand this approach sounds less crazy
> :). I think both approaches have a lot more in common than they diverge,
> so merging one in guix is just one step away of merging the other :)
>
> Having a read-only home is a fun experiment (that have been going since
> I started guix-home-manager, so it's definitely possible), but a bit
> broken, and I keep poking holes for software I can't manage properly.

I really like the idea of strict separation of configuration and state,
and read-only home sounds like a rational solution to me, however it's
not a step in the right direction, but a leap, which not possible for
many even advanced users right now.

I considered many options like read-only home, read-only ~/.config and
few others, but decided that the transition to a new tool for most people
should be iterative and as smooth as possible. It will help to grow and
educate the community before exposing them to smart and great, but very
unusual approaches.

Thus, targeted symlinking is more a social decision rather than
technical. Configs itself remain immutable, but can be mixed with files
managed by user or other software.

> Also, I had this grand vision of using "extension points" in services,
> which might be useful to have in Guix. Though I never ended up using
> them in any meaningful way ^^'.

I have a small write-up on the topic [fn:1]. From time to time I feel
restricted by service extension mechanism, I know use cases where some
improvements to the mechanism will be beneficial, but for now I would
say they are statistically insignificant and can be workarounded with
other tools.

`guix home` propose the evolutionary approach here too, we stick with
what we have in guix system service extension mechanism, make a tool to
be a part of the guix, grow user base, collect use cases hard to solve
with current capabilities, make a decision based on collected data to
improve/modify extension mechanism, which affects both `guix system` and
`guix home`.

Otherwise, we can face a problem of integration gap, which won't be
solved in years.

> Merging either of our work will make it more visible and attract more
> users/contributors, that would be great! If we settle with Andrew's
> approach, I'd be glad to provide my own services, but I will also
> probably add something to get back my dear read-only home, because
> that's the intellectually superior approach, albeit broken ;)

As I said earlier I endorse and support all the good ideas and would like
to see them in `guix home`, keeping a space for users to allow them
making one small step at a time towards wonderful world of declarative
configurations, not giant leap)

Appreciate all your ideas and the work you did on the project, I learned
quite a lot from it!

* Footnotes

[fn:1] https://lists.sr.ht/~abcdw/rde-devel/%3C87sg56g97i.fsf%40trop.in%3E

Re: guix home

[Andrew Tropin]

> I see.  So do I get it right that `guix home` focuses primarily on
> profile and user service management?  Could you give examples of a
> minimal config and command invocations?

It optionally invades in different parts of the user environment:

- Manages configurations for user programs via home-services.
- Manages a separate profile with packages declared by user or service.
- Manages shell and its environment.
- Starts a shepherd on first login and other long-living processes from
  that.
- (Not yet in master) Manages state (like cloning git repos, bringing
  folder with wallpapers from backup server on new installation),
  potentially it can not only init state, but also sync/backup/archive
  it in the future.

https://git.sr.ht/~abcdw/rde/tree/master/item/examples/home-environment.scm.tmpl
https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/README

> Oh nice, now I have to watch those!

Let me know what you think. Will be glad to hear all the comments and
suggestions on both content and delivery.

> I have yet to familiarize myself with ‘guix home’, but overall, I think
> a solution à la ‘guix home’ or guix-home-manager would be a welcome
> addition to Guix.

I would be glad to upstream it. We still completing some must have
features, home-services for important software and generic helpers for
declaring new ones. If you have any tips for simplification upstreaming
of such relatively beefy tool to keep in mind, please share them and I
hope, when `guix home` will be complete enough, the review and merge
process will be less painful.

-- 
Best regards,
Andrew Tropin

Re: guix home

[Andrew Tropin]

Joshua Branson  writes:

> I'll have to give your guix home command a try!  It sounds easy!

One of the goals is to make it effortless to use) For now we still
implement services for basic software and some fundamental features, but
in a couple of weeks plan to invite few more people to actively use
`guix home`. Follow the news on rde-announces mailing list [fn:1].

Thank you for kind supportive words!

Ryan Prior  writes:

> Thanks for sharing this Andrew, it looks awesome & I'm going to give it
> a try!

You are very welcome!)

> What do you think about changing the command? It manages user files,
> user services, user environment variables, the lifecycle of user
> sessions. So we could have "guix system" for system-level things, and
> "guix user" for user-level things.

I don't have very strong preference here and open for discussion, but
will provide my rationale for original naming:

- `guix system` manages operating systems and its generations and stuff.
- `guix package` installs, removes, upgrades packages.

Following this convention `guix user` would have to manage users, while
`guix home` manages user's home folders and related stuff. I find home
subcommand more suitable here, however other internal naming may be
temporary and is a subject to change if better options are found.

> Similarly, many of the services you describe sound to me like they
> would be easier to understand what they do with names like
> "user-service," "user-environment-vars," etc.

It's maybe true, however, the other benefit of home- naming is it makes
all the related concepts distinct. It will be harder to confuse
home-services with systemd user service for example. Still have to work
on a better naming in some places.

> I feel Guix needs something like this upstream. Whether this is the
> right implementation or not I'm not qualified to judge, but I'll read
> the source code and see what I can learn or contribute!

All the contributions from discussions to patches are welcome!)

* Footnotes

[fn:1] https://lists.sr.ht/~abcdw/rde-announce

-- 
Best regards,
Andrew Tropin

guix home

[Andrew Tropin]

Hi guix!

There is an implementation of `guix home` subcommand, which behaves
similar to `guix system`, allowing declaratively manage applications and
their configurations, but for a particular user, not the whole OS:
https://git.sr.ht/~abcdw/rde/tree/master/item/gnu

* Overview
It possible to define the desired environment with home-environment
record, which contains a list of home-services and few other
configuration options and build and install it with `guix home
reconfigure`. The service extension mechanism works the same way as in
operating-system and utilize fold-services from (gnu services).

Current set of implemented essential services:
- home-service :: return the derivation
- home-profile :: manages a separate profile with packages provided by
user or other services
- home-environment-vars :: allows to set env vars for user's shell
- home-shepherd :: manages user's shepherd, can be extended by other services
- home-run-on-first-login :: launches shepherd and some other one-time actions
- home-run-on-reconfigure :: update shepherd configuration and update
symlinks from ~/ and ~/.config to guix-home-environment/files
- home-symlink-manager :: extends on-reconfigure with a update-symlinks script

For now I personally manage just a few applications on my system and it
seems that everything works as expected, but I plan to migrate all the
"dotfiles" to it in nearest future. AFAIK, some people succesfully use
it on other GNU/Linux distributions.

* Alternative solutions
In contrast to guix-home-manager, `guix home` doesn't introduce any too
innovative approaches (those ideas are cool, but in some use cases are
too radical), `guix home` uses the same extension mechanism [fn:1] as
guix system services and doesn't require to make HOME read-only. Thus,
it's possible to start using `guix home` gradually, along with other
tools and workflows (stow, guix package, chezmoi, yadm, etc).

Talking about Nix's home-manager: it's a nice software, but maintained
separately from nix package manager and kinda disconnected from Nix
itself, which introduce a lot of duplications between NixOS modules and
home-manager modules, requires additional installation steps and overall
makes it harder to use for not very experienced nix users. Probably, we
can learn from it and do better here.

* Future steps
`guix home` still under active development, but already complete enough
for exloration and early adoption. There is no any documentation yet,
because things were changing often and probably will change one more
time during comming cleanup, however there were few video streams,
explaining internals of `guix home`:
mpv https://youtu.be/t3zRzQnarUI
mpv https://youtu.be/4lJaVzxO_Bs
mpv https://youtu.be/ZRQtCvo8MoM

In addition to documentation it will be necessary to implement a lot of
home-services for different tools, add rollback, shepherd-graph,
extension-graph and other actions, but before doing it I would like to
spend some time polishing essential services and decide on upstreaming
the tool to guix itself.

The question is: do we want and need at all `guix home` to be a part of
the guix? As for me, the tool seems like a natural addition to guix's
declarative configuration management approach and covers the missing
piece of user space software management and as I mentioned early
upstreaming will allow to make it better integrated with the rest of the
guix and easier to use for newcommers and casual users, but my
perception is obviously biased.

Dear maintainers and users, what do you think about making `guix home` a
part of guix?

* Footnotes

[fn:1] https://lists.sr.ht/~abcdw/rde-devel/%3C87sg56g97i.fsf%40trop.in%3E

--
Best regards,
Andrew Tropin

Re: [PATCH] Make assert-valid-graph public

[Andrew Tropin]

Sent to the this mailing list by mistake, please ignore it. Forwarded
to guix-patches.

On Thu, Feb 18, 2021 at 1:37 PM Andrew Tropin  wrote:
>
> I would like to reuse this function for home-shepherd-service for `guix
> home` I'm currently implementing. It seems reasonable to make this
> function public instead of copying or reimplementing it.
>


-- 
Best regards,
Andrew Tropin

[PATCH] Make assert-valid-graph public

[Andrew Tropin]

I would like to reuse this function for home-shepherd-service for `guix
home` I'm currently implementing. It seems reasonable to make this
function public instead of copying or reimplementing it.

>From ffc244f5845996bf4b0365024ac866c86cef81df Mon Sep 17 00:00:00 2001
From: Andrew Tropin 
Date: Thu, 18 Feb 2021 13:30:22 +0300
Subject: [PATCH] gnu: services: shepherd: Make assert-valid-graph public

---
 gnu/services/shepherd.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gnu/services/shepherd.scm b/gnu/services/shepherd.scm
index e2ec59f5aa..38b35b6154 100644
--- a/gnu/services/shepherd.scm
+++ b/gnu/services/shepherd.scm
@@ -73,7 +73,9 @@
 shepherd-service-back-edges
 shepherd-service-upgrade
 
-user-processes-service-type))
+user-processes-service-type
+
+assert-valid-graph))
 
 ;;; Commentary:
 ;;;
-- 
2.30.1