Re: Return back original implementation for text-config serialization

[Xinglu Chen]

Hi,

Andrew schrieb am Donnerstag der 20. Januar 2022 um 16:20 +03:

>>> 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.

From what I can tell, ‘home-files-service-type’ doesn’t seem to have
anything like that.  I am not able to find any usages for
‘computed-file’ in Guix Home services either.  I am missing something?


signature.asc
Description: PGP signature

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

[Xinglu Chen]

Andrew schrieb am Donnerstag der 23. Dezember 2021 um 16:16 +03:

>> Also, is should there be any preference for using alists or list of
>> lists or vice versa?
>
> Now it should be clear that a -configuration record is preferable as a
> service value, lists and alists are special cases for auxiliray
> services and shouldn't be used in most cases.

But what is the preference between a list and an alist?  Why does
‘etc-service-type’ use

  '((file contents))

and ‘home-file-service-type’ use

  '((file . contents))

?

>>> +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.
>>
>> Note that I already sent a patch that (at least tries to) document (gnu
>> service configuration)[1].
>>
>> One thing that is lacking is when to use (guix records) (which isn’t
>> documented yet) vs (gnu service configuration).  There should probably
>> be one or two paragraphs about that.
>>
>
> Saw it, I'll try to review and comment on it, when I'll get some spare
> time.  I'll keep this comment for now, and after the section about gnu
> service configuration module is merged, we will add links to it and
> provide more info and examples on implementing actual configurations.

It has already been merged now.  :-)

>>> +configuration file name, but in kebab-case: bashrc for bashrc,
>>
>> Not everyone might familiar with what exactly “kebab-case” means; we
>> should probably leave a footnote or something.
>>
>> “…@code{bashrc} for @file{.bashrc}…”
>>
>> It should also mention that preceding dots should be removed as well.
>> What should happend with files named ‘file.ext’?  Should the field be
>> named ‘file-ext’?
>
> Added a footnote, provided more expressive examples
> @code{bashrc} for @file{.bashrc},
> @code{bash-profile} for @file{.bash_profile},
> @code{tmux-conf} for @file{tmux.conf}, etc.

I suggested adding a footnote for the meaning of “kebab-case”.  I don’t
think these examples should just be in a footnote.  Footnotes are
usually used for stuff that might be distracting if put in the text; I
wouldn’t consider these examples distracting; they are very valuable.

>>> +bash-profile for bash_profile, etc.  The implementation for such fields
>>
>> “…@code{bash-profile} for @file{.bash_profile}.
>>
>> Also, many services have an ‘extra-content’, ‘extra-config’, or
>> ‘extra-options’ field.  In most cases these just take a string and
>> appends it to some configuration file.  Should these instead be named
>> ‘sshd_config’, ‘xserver-conf’, and ‘asound-config’, respectively?
>>
>
> I find this pattern purely-established (content vs conf vs options),
> unclear (you can never know where this extra content will be inserted
> until you take a look at implementation of serialization function)

That’s why we have documentation for all the fields.  Moreover, if it
wasn’t documented, the order of the contents of the fields of
‘home-bash-configuration’ aren’t obvious to the user either.

>>> +There is no any special requirements or
>>> +recommendations here, but it's necessary to make it possible to disable
>>> +all the effects of such fields to provide a user with an empty
>>> +configuration and let them generate it from scratch with only field for
>>> +configuration file.
>>
>> I don’t really understand what is meant by “let them generate it from
>> scratch with only field for configuration file”.  
>
> The good examples of the bad behavior are alsa and nginx service types,
> they always provide some boilerplate with reasonably good default
> configuration, but you can't alter it by setting some fields to #f or
> some other values.

That applies for the Bash service as well; it unconditionally adds stuff
to ~/.bash_profile.

> For nginx it's only partially true, you actually can use `file` field,
> but it will alter the effect of all other fields and will just use the
> file as nginx.conf, kinda conforms what I'm asking here, but makes all
> other fields useless.
>
> Added the following explanation to this item:
>
> --8<---cut here---start->8---
> For example, setting @code{guix-defaults?} to
> @code{#f} and @code{aliases} to @code{'()} will give user an ability to
> control the content of @file{.bashrc} solely by setting the value of
> @code{bashrc} field.
> --8<---cut here---end--->8---
>
>
>>
>> It doesn’t mention if a configuration record should cover all the
>> configuration options available in a configuration file.  For example,
>> the current ‘openssh-configuration’ has quite a few options, but these
>> obviously don’t cover all the options available in /etc/ssh/sshd_config,
>> which is why there is an “escape hatch”, ‘extra-content’ field.
>>
>> In 

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

[Xinglu Chen]

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.

> +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”.

> +@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

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

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

?

> +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}).

> +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
  record or a list thereof, but in some cases a simpler value is all
  that is necessary.

> +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)

It is probably better to link to the service documentation instead of
trying to explain the specification in a few words in brackets.  You can
use Texinfo “anchors” to achieve this, see “5.8 '@anchor': Defining
Arbitrary Cross-reference Targets”.

  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.

Also, is should there be any preference for using alists or list of
lists or vice versa?

> +those services are kinda special, they are an intermediate helpers
> +doing auxiliary work.

It is not clear what the 

Re: SSH service for Guix Home

[Xinglu Chen]

Hi,

Am Montag, der 20. Dezember 2021, um 23:31 +012, schrieb Ludovic Courtès 
:

> I think we need to come to a shared understanding of what the next steps
> are.  Once we have that, we can clarify the current status in the manual
> and release announcement, and open issues so that anyone who’d like to
> contribute knows where to look at.

Yeah, maybe we could create a bug report listing all the things that
should be done/fixed before we start adding too many new home services?

>> 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 :-)).
>
> I see you’ve sent it in the meantime, neat!

Andrew also sent a patch that provides some guidelines for how to write
services[1], in case you haven’t seen it already.

>> 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
>> 
>> [2]: Expected content of the serialized configuration
>> 
>
> OK.  Given that ‘define-configuration’ works at a “meta” level, I wonder
> if we could have tests that are less boring than this.

What exactly do you mean by “meta” level?  Do you have anything
particular in mind regarding the tests?

[1]: 


signature.asc
Description: PGP signature

Re: SSH service for Guix Home

[Xinglu Chen]

Hi,

Am Montag, der 20. Dezember 2021, um 13:40 +03, schrieb Andrew Tropin 
:

>>> 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.

Cool, looking forward to it!

>>> 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., —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
>> 
>> [2]: Expected content of the serialized configuration
>> 
>>
>
> 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.

Most of the service tests seem to be in tests/, e.g., tests/ssh.scm.
But since they are tests for system service, they create a VM, which is
usually overkill for testing home services.


signature.asc
Description: PGP signature

Re: SSH service for Guix Home

[Xinglu Chen]

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.  :-)

> 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!

> 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., —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

[2]: Expected content of the serialized configuration




signature.asc
Description: PGP signature

Re: Accuracy of importers?

[Xinglu Chen]

On Thu, Oct 28 2021, Ludovic Courtès wrote:

> Hello Guix!
>
> As I’m preparing my PackagingCon talk and wondering how language package
> managers could make our lives easier, I thought it’d be interesting to
> know how well our importers are doing.
>
> My understanding is that most of them require manual intervention—i.e.,
> one has to tweak what ‘guix import’ produces, even if we ignore
> synopsis/description/license, to set the right inputs, etc.  If we were
> to estimate the fraction of imported packages for which manual changes
> are needed, what would it look like?
>
>importer fraction of imported packages needing changes
>
>gnu  90% (doesn’t know about dependencies)
>pypi 50% (some miss source distro, “sdist”; some have
>  non-Python deps)
>cpan ?
>hackage  ?
>stackage (Lars?)

The Stackage is mostly based on the Hackage importer, and they are
unable to parse certains things in the .cabal files.[1][2]  I would say that
this happens maybe 1/15 to 1/20 of cases.

[1]: 
[2]: 

>egg  (Xinglu?)

I haven’t used it that much, but I would say it works ~80%.  Some
egg packages specify system dependencies (e.g., OpenSSL), but the
importer doesn’t know what the name of that package is in Guix, so it’s
not always correct.

> What about licensing info: which ones provide accurate licensing info?
> My guess:
>
>gnu
>pypi
>cpan
>cran
>elpa
>go (?)
>cran
>crate (?)
>texlive
>opam (?)
>minetest (?)

For the egg importer, many packages specify the wrong license in their
.egg file, and there is no convention for what naming scheme to use, so
sometimes it is ‘GPL3’, other times it is ‘GPL-3.0’.

The Hackage/Stackage importer generally results in correct licenses, so
I would also put it on this list.  :-)


signature.asc
Description: PGP signature

Re: Merging wip-guix-home to master

[Xinglu Chen]

On Wed, Sep 29 2021, Katherine Cox-Buday wrote:

> Xinglu Chen  writes:
>
>> 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.
>
> I strongly disagree with this. As a long-time developer, I have used
> documentation both as a user and as a developer many times.
>
> Documentation is for everyone.

I said “to not be documented in the manual” (the majority of (guix …)
modules aren’t documented in the manual); that doesn’t mean that there
aren’t any docstrings.  The manual says that all top-level procedures
should have docstrings (see “16.5.4 Formatting Code”)

We require all top-level procedures to carry a docstring.  This
  requirement can be relaxed for simple private procedures in the ‘(guix
  build ...)’ name space, though.



signature.asc
Description: PGP signature

Re: Merging wip-guix-home to master

[Xinglu Chen]

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,

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.

[Xinglu Chen]

On Tue, Sep 28 2021, 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?

I think it would be better to put home services in the same modules as
system services, i.e., (gnu services mcron) would contain the Mcron
service for Guix System and the Mcron service for Guix Home.  That would
also mean that we wouldn’t have to export ‘job-files’ and
‘shepherd-schedule-action’[1].

I think using (gnu home services …) would only make sense if we already
had (gnu system services …).

WDYT?

[1]: 


signature.asc
Description: PGP signature

Re: Merging wip-guix-home to master

[Xinglu Chen]

On Tue, Sep 28 2021, Ludovic Courtès wrote:

> Xinglu Chen  skribis:
>
>> 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.
>
> Agreed.  There are a few (very few) exceptions, but in general each
> command needs (1) a section in the manual and (2) unit tests and/or
> integration tests in a shell script.
>
> Could you submit patches for that?

Sure!  :-)

> IWBN if others could do an after-the-fact review of the code, too.

Agreed.  I quickly skimmed through (gnu home-services xdg), and I can
already see some things that can be improved.  :-)

>> I just realized that it generates the following service declaration
>>
>> (service
>>  home-bash-service-type
>>  (home-bash-configuration
>>   (bashrc
>>(list (slurp-file-gexp
>>   (local-file "/home/yoctocell/.bashrc"))
>>
>> 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…
>
> Also, I argued earlier against ‘slurp-file-gexp’:
>
>   https://lists.gnu.org/archive/html/guix-devel/2021-06/msg00192.html
>
> I haven’t checked the different service configuration APIs, but I think
> we should avoid uses of ‘slurp-file-gexp’ entirely and instead do the
> same as in the majority of Guix System services, which is to accept
> file-like objects.
>
> Thoughts?  Could you take a look?

Yeah, I never really liked ‘slurp-file-gexp’; using ‘local-file’ &
co. would be better and more consistent.


signature.asc
Description: PGP signature

Re: branch core-updates-frozen updated: services: database: Change postgresql default socket.

[Xinglu Chen]

On Mon, Sep 27 2021, Mathieu Othacehe wrote:

> Hello,
>
>> The manual should also be updated to reflect this change.
>
> Fixed, thanks for the reminder.

You are welcome!  :-)

>> Also, is there any reason for making this change on
>> ‘core-updates-frozen’ rather than ‘master’?
>
> Yes, that's a follow-up of 86cf4c039631cdf15c4c428bf4ffe52d6cbd7d4c that
> was pushed on core-updates a while ago.

Ah, OK.


signature.asc
Description: PGP signature

Re: branch core-updates-frozen updated: services: database: Change postgresql default socket.

[Xinglu Chen]

On 27 September 2021 15:26, guix-comm...@gnu.org wrote:

> commit 502925655d1a51aad544804c8ef492a5d24e1776
> Author: Mathieu Othacehe 
> AuthorDate: Mon Sep 27 19:22:56 2021 +
>
> services: database: Change postgresql default socket.
>
> Adapt to the postgresql default socket directory set to 
> /var/run/postgresql.
>
> * gnu/services/databases.scm 
> ()[socket-directory]: Set
> to /var/run/postgresql.
> (): Ditto.
> * gnu/tests/databases.scm (run-postgresql-test): Adapt it.
> ---
>  gnu/services/databases.scm | 4 ++--
>  gnu/tests/databases.scm| 3 +--
>  2 files changed, 3 insertions(+), 4 deletions(-)

The manual should also be updated to reflect this change.

Also, is there any reason for making this change on
‘core-updates-frozen’ rather than ‘master’?




signature.asc
Description: PGP signature

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

[Xinglu Chen]

On Fri, Sep 24 2021, 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?.

I didn’t know about the parent mechanism; that could be an approach to
take.  But since ‘define-configuration’ is based on (guix records),
would it make sense to adapt (guix records) to (rnrs records syntactic)
instead of SRFI-9 records?



signature.asc
Description: PGP signature

Re: Merging wip-guix-home to master

[Xinglu Chen]

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 114Sep 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…



signature.asc
Description: PGP signature

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

[Xinglu Chen]

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.

It’s probably going to be quite complicated, so it would be good to get
some feedback/thoughts on it.  Cc Maxim since he has done some work with
(gnu services configuration).

Also, it’s probably time to properly document (gnu services
configuration) in the manual.  ;-)

> 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?

I am not sure exactly what you mean here, could you elaborate?



signature.asc
Description: PGP signature

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

[Xinglu Chen]

On Fri, Sep 17 2021, Andrew Tropin wrote:

> 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."
&

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

[Xinglu Chen]

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.  :-)

>> 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 also have a ‘define-home-configuration’ macro that would create
>> a  record and optionally, a
>>  record.  Then ‘home-service?’ would be
>> ‘system-service?’ instead.
>>
>> Maybe it’s too complicated and not worth it, but it’s just an idea I
>> have had.
>>
>
> define-configuration is already a quite complicated macro, but maybe
> something like that will work, still unhappy with tons of macros for
> implementing records in scheme (:
>
>>
>>> 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.
>
> The system and home services can't really integrate with each other at
> least because of extension mechanism.
>
>> 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.
>>
>
> Yes, but with Guix System and Guix Home it's easier to keep them in sync
> and share code between them because they are both a part of the same
> repo.
>
> Going back to intersection: Yes, there are some services that are common
> to Guix Home and System: mcron, shepherd and maybe a few more, but most
> 

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

[Xinglu Chen]

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.

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 also have a ‘define-home-configuration’ macro that would create
a  record and optionally, a
 record.  Then ‘home-service?’ would be
‘system-service?’ instead.

Maybe it’s too complicated and not worth it, but it’s just an idea I
have had.

> 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 

Re: Can we find a better idiom for unversioned packages?

[Xinglu Chen]

On Fri, Sep 03 2021, Leo Famulari wrote:

> On Fri, Sep 03, 2021 at 06:11:46PM +0200, Xinglu Chen wrote:
>> The date does give an idea of how old the version is, compare that to a
>> random string of 7 characters.  If a user wants to know the exact
>> commit, they can always just run ‘guix edit PACKAGE’ and check the
>> ‘commit’ field in the source of the package.
>
> That's true.
>
> However, it's not easy to figure out which revision of guix.git produced
> a package that is installed in a profile.

‘guix describe’ would show the commit of the guix.git repo used,
wouldn’t it?

> The transformation from package definition to built package is lossy.
> You cannot take a built package and ask Guix "which guix.git commit was
> used for this?"
>
> So, if I have a package foo-0.0.0-1-2021-12-31 in my profile, it's
> impossible to reliably trace that back to the correct Guix package
> definition and then discover what upstream source code it was built
> with. [0] On the other hand, if the package's version includes the Git
> commit, it's trivial.

Good point, I don’t really have a good solution to that.

> So, I think we each have different needs that we want satisfied:
>
> 1) To know how old the package's source code is
> 2) To know what source code a built package is based on
>
> The second item is something I do often, and I think a lot of Guix
> developers do it too. And in general, it's imporant for store paths to
> include meaningful "version" information; a date is not meaningful in
> this sense. So let's be careful not to lose that ability by removing
> commit IDs from the package versions.
>
> We can satisfy both of these by adding the date to the version string,
> although we should be careful not to risk exceeding Linux's shebang
> length limit (127), which sometimes will crop up if packages provide
> shebang-able interpreters. The store path needs to be short enough that
> the "bin/foo" part does not make the absolute path exceed 127
> characters. This is something that was addressed while designing the
> current versioning for VCS snapshots.

I didn’t know Linux had this weird(?) restriction, but yeah, it will be
something to think about.

> I'm still skeptical of the utility of adding a date, given the lack of
> useful time information conveyed by Git, but if people really want it
> and it can be made to work, then we should go ahead.

If the date is not part of the version string, I think that there should
at least be a comment saying the the date of the commit, just to let
other people quickly see how old the version is.



signature.asc
Description: PGP signature

Re: [bug#50077] Separate ‘emacs’ output vs separate ‘emacs-’ package (was Re: [bug#50077] [PATCH 1/3] gnu: notmuch: Add separate 'emacs' output.)

[Xinglu Chen]

On Thu, Sep 02 2021, Carlo Zancanaro wrote:

> On Wed, Sep 01 2021, Liliana Marie Prikler wrote:
>> TL;DR: I'm generally in favor of branching emacs support 
>> packages off, even if origins are to be inherited.
>
> This is my preference, and there is precedent for this in Guix 
> already. I know of emacs-protobuf-mode and emacs-erlang which are 
> separate packages, but which reference the source of an existing 
> package (with (package-source protobuf) and (package-source 
> erlang), respectively).
>
> I like how easy it is to discover Emacs packages by looking for 
> the emacs- prefix. Mu and notmuch already violate that prefix 
> expectation, moving their elisp into a separate output would be 
> further hiding the Emacs modes.
>
> Carlo

Looks like there is consensus on the matter, unless someone objects, I
will send an updated series that adds ‘emacs-notmuch’ instead of adding
an extra output to ‘notmuch’.  :-)


signature.asc
Description: PGP signature

Re: Can we find a better idiom for unversioned packages?

[Xinglu Chen]

On Thu, Sep 02 2021, Leo Famulari wrote:

> On Thu, Sep 02, 2021 at 12:51:58PM -0400, Leo Famulari wrote:
>> On Wed, Sep 01, 2021 at 06:50:36PM +0200, Xinglu Chen wrote:
>> > > Commit dates don't have a consistent meaning: are they the time of
>> > > first revision of a commit? Final revision of a commit? Time of
>> > > signing? Pushing? They are often useful to estimate a timeline, but
>> > > it's common for a Git "timeline" to jump back and forth by months or a
>> > > year due to long-running development branches being merged in, or due
>> > > to a "commit and then polish by rebasing" workflow.
>> > 
>> > I would say the the time of the final commit would be the best option,
>> > but I agree that it can be ambiguous.
>
> Reading your message again, I think you misunderstood what I wrote.
>
> I wasn't asking what date we should choose to include in our package
> versions. I was asking, "What does the Git commit timestamp describe?"
> And the answer is that there is not a clear answer, and it depends on
> the workflow of the person who made the Git commit. My point being that
> a Git repo does not offer us meaningful information about when anything
> happened.

The date does give an idea of how old the version is, compare that to a
random string of 7 characters.  If a user wants to know the exact
commit, they can always just run ‘guix edit PACKAGE’ and check the
‘commit’ field in the source of the package.

From a Guix developer’s perspective, one can get an idea of roughly how
old a package is when looking at the package definition.  E.g., a few
months ago, when Magit hadn’t a release for around 2 years or so, I
wanted to see how old our current ‘emacs-magit’ package was.  To do that
I had to ‘guix edit emacs-magit’, then find the commit-id and copy it,
then go to my local checkout of Magit and run ‘git log COMMIT-ID’, just
to see how old the version was.  If the date of the commit was encoded
in the version string, I would immediately see that its 6 months old or
something; no need to manually look up the commit-id.


signature.asc
Description: PGP signature

Re: Can we find a better idiom for unversioned packages?

[Xinglu Chen]

On Wed, Sep 01 2021, Leo Famulari wrote:

> On Wed, Sep 1, 2021, at 06:55, Xinglu Chen wrote:
>> I never felt like including the commit id in the version of a package
>> was useful; e.g., just seeing the first seven characters of the commit
>> id doesn’t really tell me anything about the version.  I think it is
>> more useful to put the date of the commit in the version; Nixpkgs does
>> something like this[1].  I have started to put the date of the commit in
>> a comment, just to make it easier for people to know how old it commit
>> is; otherwise, one would have to find the VCS repo and find the commit
>> just to see how old the commit is.
>
> The issue I see with only using the date is that Git dates are not
> unique, in order, or even meaningful in a clear way.

Well, seeing

  foo-1.0.0-1.2021-01-31

gives a user more useful information than something like

  foo-1.0.0-1.cabba9e

With the former, I can quickly see that the version is from 2021-01-31,
whereas with the latter, I would have to either find the VCS repo online
or go to my local checkout of it and browse the logs.

> Commit dates don't have a consistent meaning: are they the time of
> first revision of a commit? Final revision of a commit? Time of
> signing? Pushing? They are often useful to estimate a timeline, but
> it's common for a Git "timeline" to jump back and forth by months or a
> year due to long-running development branches being merged in, or due
> to a "commit and then polish by rebasing" workflow.

I would say the the time of the final commit would be the best option,
but I agree that it can be ambiguous.

> Using the revision ID (of sufficient length) gives an unambiguous
> reference to the upstream source of a package and its artifacts in the
> store. How would you describe a package version to upstream when
> reporting a bug, except by revision ID? You can't tell them a
> timestamp and expect them to know which code a buggy package is based
> on.

One can get the commit id of a package by simply running ‘guix edit
PACKAGE’ and copying the commit id from the package definition.  I don’t
think hiding the commit id from the package version would be a problem
for this situation.

> We could certainly add a timestamp to our version strings for
> VCS-based packages, but we should keep the revision ID too.

I haven’t really found the commit id that useful when looking at the
version of a package; adding a timestamp would certainly be better than
the status quo.  :-)


signature.asc
Description: PGP signature

Re: Can we find a better idiom for unversioned packages?

[Xinglu Chen]

On Tue, Aug 31 2021, Maxime Devos wrote:

> Sarah Morgensen schreef op di 31-08-2021 om 12:57 [-0700]:
>> Hello Guix,
>> 
>> Currently, there are about 1500 packages defined like this:
>> 
>> --8<---cut here---start->8---
>> (define-public sbcl-feeder
>>   (let ((commit "b05f517d7729564575cc809e086c262646a94d34")
>> (revision "1"))
>> (package
>>   [...])))
>> --8<---cut here---end--->8---
>> 
>> I feel like there are some issues with this idiom (in no particular
>> order):
>> 
>> 1. When converting between this idiom and regularly versioned packages,
>> the git diff shows the whole package changing because of the indentation
>> change.
>> 
>> 2. We cannot get at the source location for the definition of 'commit' or
>> 'revision'.  This would be useful for updating these packages with `guix
>> refresh -u`.  There is a proposed patch [0] to work around this, but it
>> *is* a workaround.
>> 
>> 3. Packages inheriting from it lose the definitions.  For actual fields,
>> we have e.g. `(package-version this-package)`, but we have no equivalent
>> for these.
>> 
>> 4. Horizontal space is at a premium, and an extra two spaces here and
>> there add up.  (Personally, I think we could do with a
>> define-public-package macro to save another two spaces, but that's for
>> another day...)
>> 
>> 5. The closest thing we have to a standardized way of generating
>> versions for these packages is `(version (git-version "0.0.0" revision
>> commit))`.  We can do better than that boilerplate.
>
> Suggestion: extend the 'version' field.  More specifically,
> introduce a new record , like this:
>
> (define-record-type*  extended-version make-extended-version
>   extended-version? this-version
>   ;; something like 1.2.3 (TODO better name)
>   (base extended-version-base)
>   (revision extended-version-revision)
>   (commit extended-version-commit))
>
> (define (version->string version)
>   (match version
> ((? string?) version)
> (($  ...) code from original git-version  and 
> hg-version)))
>
> ;; TODO:
> ;; adjust git-file-name and hg-file-name to accept  records
> ;; (as well as the ‘old style’ for compatibility)
>
> To be used like:
>
> (define-public sbcl-feeder
>   (name "sbcl-feeder")
>   (version (extended-version
>  (base "1.0.0")
>  (revision 1)
>  (commit "b05f517d7729564575cc809e086c262646a94d34")))
>  (source
>   (origin
> (method git-fetch)
> (uri (git-reference ...)
>(url ...)
>;; git-reference needs to be extended to retrieve the commit from 
> the version
>(version version)))
> (file-name (git-file-name "feeder" version))
> (sha256 ...)))
>  [...])

How will this work for SVN and CVS?  I am not familiar with either, but
I know that SVN has its own ‘revision’ thing.


signature.asc
Description: PGP signature

Re: [bug#50077] Separate ‘emacs’ output vs separate ‘emacs-’ package (was Re: [bug#50077] [PATCH 1/3] gnu: notmuch: Add separate 'emacs' output.)

[Xinglu Chen]

On Wed, Sep 01 2021, Andrew Tropin wrote:

> On 2021-08-30 15:33, Xinglu Chen wrote:
>
>> On Mon, Aug 30 2021, Andrew Tropin wrote:
>>
>>>> Why would it be more consistent to make a separate package?  Making a
>>>> separate package is usually used for packaging a slightly different
>>>> version of the “regular” package, e.g., ‘emacs-next-pgtk’ adds native
>>>> compilation and pure GTK support for Emacs., ‘emacs-no-x’ removes X
>>>> suport for ‘emacs’.  ‘emacs-notmuch’ isn’t really a different version of
>>>> ‘notmuch’, it’s just ‘notmuch’ but with all the non-Elisp stuff
>>>> removed.  This is usually what using different outputs tries to achieve,
>>>> e.g., separate documentation from the main package, or in this case,
>>>> separate Elisp stuff from the main package.
>>>>
>>>
>>> Almost all elisp packages in Guix have a emacs- prefix, so as a user I
>>> expect to find notmuch*.el in emacs-notmuch package and notmuch binary
>>> in notmuch package, despite the fact that upstream distributes the
>>> source code for both of them in one tarball.
>>
>> Good point, however, If we were to have separate ‘emacs-’ packages for
>> the packages that also contain Elisp stuff, should those packages still
>> include the Emacs package in their output, i.e., should the ‘notmuch’
>> package still include notmuch.el, or should the Elisp stuff only be in
>> ‘emacs-notmuch’?
>>
>
> IMO, notmuch package should not include Elisp stuff, at least I don't
> see use cases, where it can be useful, but see where it can be
> harmful.

Should this apply to other packages that contains Elisp stuff too, or is
it specific to ‘notmuch’?

Cc’ing guix-devel to see what other people think before we start
breaking people’s setups.  :-)


signature.asc
Description: PGP signature

Re: Can we find a better idiom for unversioned packages?

[Xinglu Chen]

On Tue, Aug 31 2021, Sarah Morgensen wrote:

> Hello Guix,
>
> Currently, there are about 1500 packages defined like this:
>
> --8<---cut here---start->8---
> (define-public sbcl-feeder
>   (let ((commit "b05f517d7729564575cc809e086c262646a94d34")
> (revision "1"))
> (package
>   [...])))
> --8<---cut here---end--->8---
>
> I feel like there are some issues with this idiom (in no particular
> order):
>
> 1. When converting between this idiom and regularly versioned packages,
> the git diff shows the whole package changing because of the indentation
> change.
>
> 2. We cannot get at the source location for the definition of 'commit' or
> 'revision'.  This would be useful for updating these packages with `guix
> refresh -u`.  There is a proposed patch [0] to work around this, but it
> *is* a workaround.
>
> 3. Packages inheriting from it lose the definitions.  For actual fields,
> we have e.g. `(package-version this-package)`, but we have no equivalent
> for these.
>
> 4. Horizontal space is at a premium, and an extra two spaces here and
> there add up.  (Personally, I think we could do with a
> define-public-package macro to save another two spaces, but that's for
> another day...)
>
> 5. The closest thing we have to a standardized way of generating
> versions for these packages is `(version (git-version "0.0.0" revision
> commit))`.  We can do better than that boilerplate.
>
> 6. Not a direct complaint, but I feel like the overall package interface
> was designed before straight-from-vcs unversioned packages were so
> common, and so this idiom developed organically to work around that.
>
> I do not have a specific solution in mind, but I think there must be
> one.  I do have a few half-baked ideas, but I'm curious what we can all
> come up with together.  Or maybe you'll just tell me I'm just being
> awfully picky :)
>
> [0] https://issues.guix.gnu.org/50286

I never felt like including the commit id in the version of a package
was useful; e.g., just seeing the first seven characters of the commit
id doesn’t really tell me anything about the version.  I think it is
more useful to put the date of the commit in the version; Nixpkgs does
something like this[1].  I have started to put the date of the commit in
a comment, just to make it easier for people to know how old it commit
is; otherwise, one would have to find the VCS repo and find the commit
just to see how old the commit is.

--8<---cut here---start->8---
(define-public foo
  ;; No tags; commit from -MM-DD.
  (let ((commit "COMMIT-ID")
(revision "1"))
(package
  ...)))
--8<---cut here---end--->8---

Instead of having showing something like

  foo-1.0.0-1.cabba9e

users would see

  foo-1.0.0-1.2021-01-31


Just my 2€  :-)

[1]: 



signature.asc
Description: PGP signature

Re: Create branch for Haskell build changes and updates?

[Xinglu Chen]

On Wed, Jul 21 2021, Ricardo Wurmus wrote:

> Xinglu Chen  writes:
>
>> Thank you for bringing this up!  I posted a WIP patch for adding 
>> GHC
>> 8.10 a while ago, but nobody showed any interest[1].
>>
>> I don’t have any experience with updating the Haskell toolchain 
>> in Guix,
>> but I think it would be great to have a separate branch for 
>> updating the
>> haskell-build-system and Haskell packages.  :)
>>
>> [1]: https://yhetil.org/guix-devel/87o8cgfbg1@yoctocell.xyz/
>
> It would be good to send this to guix-patc...@gnu.org instead of 
> guix-devel.  Please also see the Contributing section in the 
> manual.

I asked on guix-devel to see if anybody was interested in an Haskell
update; I just attached a WIP patch to see if anyone would be interested
in helping out, since I didn’t really know where to start.  Sending it
to guix-patches would make it more likely to be forgotten since it
is a higher-volume list.

Now that more people have showed interest, I recently sent a patch for
it to guix-patches[1].  I still have to address some failing tests
before it’s ready to merge.  :)

[1]: https://issues.guix.gnu.org/49606


signature.asc
Description: PGP signature

Re: Create branch for Haskell build changes and updates?

[Xinglu Chen]

On Fri, Jul 09 2021, John Kehayias wrote:

> On Friday, July 9th, 2021 at 10:06 AM, Ricardo Wurmus wrote:
>> Sorry, not this time :)
>>
>> I suggest just starting a new branch. It doesn’t really need to
>>
>> be hosted in the main repo at this point, but if you have some
>>
>> initial patches that you’d like me to push to wip-haskell feel
>>
>> free to send them.
>>
> Hi Ricardo,
>
> Yes, we could have a repo anywhere, but what (at least) I was getting
> at was having some CI support to build Haskell packages to find any
> breakage. Even without being on the main repo could we do that?
> Changes I've made locally and packages I've tried to add (which might
> need version bumps of others) lead to a ton of compile time.

Agreed, I only have one machine, and compiling GHC on it takes 3-4
hours.  Having CI compiling that and all the haskell packages would be
nice.


signature.asc
Description: PGP signature

Re: Use of %texlive-revision and %texlive-tag in tex.scm

[Xinglu Chen]

FYI, someone else is already workin on upgrading Texlive to 2021 on the
‘core-updates’ branch (Texlive is already at 2020 on core-updates).

  

Maybe you would be interested in helping out? 

Re: Early feedback on Guix Home

[Xinglu Chen]

On Tue, Jun 29 2021, Ludovic Courtès wrote:

> 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.

How would we do that?  Would we use (G_ ...) or something?

>>> 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.

Yeah, I will look more into adding something like this.


signature.asc
Description: PGP signature

Re: Early feedback on Guix Home

[Xinglu Chen]

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?

>   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 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
>  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.

> That’s it.  I hope it makes sense to you!

Thank you for the feedback!  Great to see that people are using and
enjoying Guix Home :)

> I encourage everyone to give it a spin, fearlessly!
> What I did was (roughly):
>
>   git clone 

Haskell update (was: Release 1.2.1: Cuirass failed to build Haskell 179 packages)

[Xinglu Chen]

On Tue, Mar 23 2021, zimoun wrote:

>> Maybe its time to update to a newer Stackage LTS release? :)
>
> Well, I do not know if it possible to do so before the next release.
> IMHO, let focus on what remains for the next release and let upgrade the
> Stackage LTS after.

Any updates on this?  I managed to build GHC 8.10.5 (on x86_64), but I
had to disable some tests.  I have attached the patch if anyone wants to
take a look.  :)

From 9ecfe7cb3f94b928dbd883d4b7e7c007278c0fa8 Mon Sep 17 00:00:00 2001
Message-Id: <9ecfe7cb3f94b928dbd883d4b7e7c007278c0fa8.1623177424.git.pub...@yoctocell.xyz>
From: Xinglu Chen 
Date: Tue, 18 May 2021 23:32:38 +0200
Subject: [RFC PATCH] gnu: Add ghc-8.10.

* gnu/packages/haskell.scm (ghc-8.10): New variable.
---
 gnu/packages/haskell.scm | 66 
 1 file changed, 66 insertions(+)

diff --git a/gnu/packages/haskell.scm b/gnu/packages/haskell.scm
index 09732fc594..8de3118136 100644
--- a/gnu/packages/haskell.scm
+++ b/gnu/packages/haskell.scm
@@ -657,6 +657,72 @@ interactive environment for the functional language Haskell.")
 (file-pattern ".*\\.conf\\.d$")
 (file-type 'directory))
 
+(define-public ghc-8.10
+  (package
+(inherit ghc-8.8)
+(name "ghc")
+(version "8.10.5")
+(source
+ (origin
+   (method url-fetch)
+   (uri (string-append "https://www.haskell.org/ghc/dist/;
+   version "/ghc-" version "-src.tar.xz"))
+   (sha256
+(base32 "0vq7wch0wfvy2b5dbi308lq5225vf691n95m19c9igagdvql22gi"
+(native-inputs
+ `(("ghc-bootstrap" ,ghc-8.6)
+   ("ghc-testsuite"
+,(origin
+   (method url-fetch)
+   (uri (string-append
+ "https://www.haskell.org/ghc/dist/;
+ version "/ghc-" version "-testsuite.tar.xz"))
+   (patches (search-patches "ghc-testsuite-dlopen-pie.patch"))
+   (sha256
+(base32
+ "0vcq774rfb6q8vsnh7p5clxp2qaz8ip6d2bm2ghbq53n8jl296d6"
+   ("git" ,git-minimal) ; invoked during tests
+   ,@(filter (match-lambda
+   (("ghc-bootstrap" . _) #f)
+   (("ghc-testsuite" . _) #f)
+   (_ #t))
+ (package-native-inputs ghc-8.6
+(arguments
+ (substitute-keyword-arguments (package-arguments ghc-8.6)
+   ((#:phases phases '%standard-phases)
+`(modify-phases ,phases
+   (add-after 'unpack-testsuite 'skip-more-tests
+ (lambda _
+   ;; XXX: This test fails because our ld-wrapper script
+   ;; mangles the response file passed to the linker.
+   (substitute* "testsuite/tests/hp2ps/all.T"
+ (("^test\\('T15904'") "# guix skipped: test('T15904'"))
+   ;; The following tests fail because they are unable to
+   ;; find a C compiler.
+   (substitute* "testsuite/tests/hsc2hs/all.T"
+ (("^test\\('" all)
+  (string-append "# guix skipped: " all)))
+   (substitute* "testsuite/tests/ffi/should_run/all.T"
+ (("^test\\('Capi_Ctype_00(1|2)'" all)
+  (string-append "# guix skipped: " all)))
+   (substitute* "testsuite/tests/ffi/should_run/all.T"
+ (("makefile_test, \\['Capi_Ctype_00(1|2)'\\].*" all)
+  (string-append "# guix skipped: " all)))
+   (substitute* "libraries/base/tests/IO/T12010/test.T"
+ (("^.*" all)
+  (string-append "# guix skipped: " all)))
+   ;; No idea why these are failing
+   (substitute* '("testsuite/tests/driver/T8602/T8602.T"
+  "testsuite/tests/driver/T16521/all.T")
+ (("^.*" all)
+  (string-append "# guix skipped: " all)
+(native-search-paths (list (search-path-specification
+(variable "GHC_PACKAGE_PATH")
+(files (list
+(string-append "lib/ghc-" version)))
+(file-pattern ".*\\.conf\\.d$")
+(file-type 'directory))
+
 (define-public ghc-8 ghc-8.6)
 
 (define-public ghc ghc-8)

base-commit: 503c2039a280dd52a751a6852b4157fccd1b4195
-- 
2.32.0



signature.asc
Description: PGP signature

Re: unifying mcron and shepherd, service woes, improvements

[Xinglu Chen]

On Sat, May 15 2021, raingloom wrote:

> Just throwing this out there:
> mcron is basically a very simple service manager, so, why not just move
> all its timer functionality into shepherd (like systemd's timer units)
> and then we can have a unified way to manage and debug services.

Yes please!

Not really related to Shepherd or Mcron, but having something like
Syslogd/Journald at the user level to browse and rotate logs would be
nice.


signature.asc
Description: PGP signature

Re: Add a way to disable serialization support to (guix services configuration)

[Xinglu Chen]

Hi Maxim,

On Fri, May 07 2021, Maxim Cournoyer wrote:

> Hello Xinglu!
>
> Thank you for working on it!

You are very welcome!  These are things that have annoyed me enough so I
decided (try) to fix it myself :)

>> +(define (configuration-no-default-value kind field)
>> +  (configuration-error
>> +   (format #f "`~a' in `~a' does not have a default value" kind field)))
>
> The kind and field should be inverted.

Good catch

>>configuration-field make-configuration-field configuration-field?
>> @@ -112,7 +116,7 @@
>>  (define-syntax define-configuration
>>(lambda (stx)
>>  (syntax-case stx ()
>> -  ((_ stem (field (field-type def) doc) ...)
>> +  ((_ stem (field (field-type properties ...) doc) ...)
>
> I'd rather keep the 'def' binding for the default value; properties is
> too vague and implies many of them, which is not a supported syntax.

Yeah, not exactly sure why I changed it to ‘properties’, anyway...

>> (with-syntax (((field-getter ...)
>>(map (lambda (field)
>>   (id #'stem #'stem #'- field))
>> @@ -121,36 +125,56 @@
>>(map (lambda (type)
>>   (id #'stem type #'?))
>> #'(field-type ...)))
>> + ((field-default ...)
>> +  (map (match-lambda
>> + ((field-type default _ ...) default)
>> + ;; We get warnings about `disabled' being an
>> + ;; unbound variable unless we quote it.
>> + (_ (syntax 'disabled)))
>
> Here I think it'd be better to have the pattern more strict (e.g,
> (field-type default-value) or (field-type); so as to not accept invalid
> syntax.

Good point!

> I also think it'd be clearer to use another symbol than 'disabled, as
> this already has a meaning for the validator and could confuse readers.

Yeah, it’s not very descriptive.

>> +   #'((field-type properties ...) ...)))
>>   ((field-serializer ...)
>>(map (lambda (type)
>>   (id #'stem #'serialize- type))
>> #'(field-type ...
>> -   #`(begin
>> -   (define-record-type* #,(id #'stem #'< #'stem #'>)
>> - #,(id #'stem #'% #'stem)
>> - #,(id #'stem #'make- #'stem)
>> - #,(id #'stem #'stem #'?)
>> - (%location #,(id #'stem #'-location)
>> -(default (and=> (current-source-location)
>> -source-properties->location))
>> -(innate))
>> - (field field-getter (default def))
>> - ...)
>> -   (define #,(id #'stem #'stem #'-fields)
>> - (list (configuration-field
>> -(name 'field)
>> -(type 'field-type)
>> -(getter field-getter)
>> -(predicate field-predicate)
>> -(serializer field-serializer)
>> -(default-value-thunk (lambda () def))
>> -(documentation doc))
>> -   ...))
>> -   (define-syntax-rule (stem arg (... ...))
>> - (let ((conf (#,(id #'stem #'% #'stem) arg (... ...
>> -   (validate-configuration conf
>> -   #,(id #'stem #'stem #'-fields))
>> -   conf
>> + #`(begin
>> + (define-record-type* #,(id #'stem #'< #'stem #'>)
>> +   #,(id #'stem #'% #'stem)
>> +   #,(id #'stem #'make- #'stem)
>> +   #,(id #'stem #'stem #'?)
>> +   (%location #,(id #'stem #'-location)
>> +  (default (and=> (current-source-location)
>> +  source-properties->location))
>> +  (innate))
>> +   #,@(map (lambda (name getter def)
>> + (if (equal? (syntax->datum def) (quote 'disabled))
>
> nitpick: eq? suffices to check for symbols.
>
>> + #`(#,name #,getter)
>> + #`(#,name #,getter (default #,def
>> +   #'(field ...)
>> +   #'(field-getter ...)
>> +   #'(field-default ...)))
>> + (define #,(id #'stem #'stem #'-fields)
>> +   (list (configuration-field
>> +  (name 'field)
>> +  (type 'field-type)
>> +  (getter field-getter)
>> +  (predicate field-predicate)
>> +  (serializer field-serializer)
>> +  ;; TODO: What if there is no default value?
>
> Seems 

Re: [PATCH 0/2] Add mercurial-commitsigs and some changes to Mercurial.

[Xinglu Chen]

Whoops wrong list, that was why I didn’t get a message back from Debbugs.

[PATCH 0/2] Add mercurial-commitsigs and some changes to Mercurial.

[Xinglu Chen]

The first patch adds the commitsigs extension for Mercurial, it allows
users to sign Mercurial changesets (equivalent to Git commits) with
GnuPG or OpenSSL.

The second patch adds PYTHONPATH to the ‘native-search-paths’ field of
Mercurial, this allows Mercurial to automatically find third-party
extensions (like commitsigs) installed in
/gnu/store/...-profile/lib/python3.8/site-packages/hgext3rd.  By
default, it only looks at
/gnu/store/...-mercurial/lib/python3.8/site-packages/hgext3rd.

However, I am not sure this is the best approach since it messes with
PYTHONPATH, AFAIK there is no such things as a HGEXTENSIONS variable I
could set.  Another problem is that I have to hardcode “python3.8”, this
would obviously have to be updated if the default Python version gets
updated.  I did try to do something like this:

#+begin_src scheme
(string-append
  "lib/python"
  (string-join
(drop-right (string-split (package-version python) #\.) 1)
".")
  "/site-packages/hgext3rd")
#+end_src

but it just gave me a confusing error message when trying to build it;
it worked fine if I hit {C-x C-e} in Emacs, though.

What we could do instead is to delegate the work of installing Mercurial
extensions to Guix Home[1] (I am currently working on adding a service
for Mercurial[2]) and add a ‘mercurial-extension-file-path’ key to the
‘properties’ field of Mercurial extensions so Guix Home can tell
Mercurial where to find the extension by the relevant lines in hgrc.  We
could have a package definition like this:

#+begin_src scheme
(package
  (name "mercurial-commitsigs")
  ...
  (properties
   '((mercurial-extension-file-path . "commitsigs.py"
#+end_src

hgrc:

#+begin_src
[extensions]
commitsigs = /gnu/store/...-mercurial-commitsigs/commitsigs.py
#+end_src

[1]: https://yhetil.org/guix-devel/878s6u2pco@trop.in/
[2]: https://lists.sr.ht/~abcdw/rde-devel/patches/22421

Xinglu Chen (2):
  gnu: Add mercurial-commitsigs.
  gnu: mercurial: Add PYTHONPATH to ‘native-search-paths’.

 gnu/packages/version-control.scm | 68 
 1 file changed, 68 insertions(+)


base-commit: aa7eeabe9a782afc2535581298990050d16b1895
-- 
2.31.1

Re: Guix Home upstreaming plan

[Xinglu Chen]

Hi,

On Fri, Apr 30 2021, Ludovic Courtès wrote:

> Hi Andrew,
>
> Andrew Tropin  skribis:
>
>> 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.
>
> 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!

There is also a development mailing list[1] if you want to get a better
idea of what’s currently cooking. :)

> Since this kind of tool is rather unusual (there’s no real equivalent
> I’m aware of in other distros)

Nix Home Manager[2] is very similar to Guix Home, it allows for the same
kind of declarative configuration as Guix Home, but using Nix.  I have
been using and hacking on Guix Home on NixOS and it’s getting closer to
replacing Nix Home Manager for me. :)

> 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.)

Plus user packages and state management, e.g. automatically cloning Git
repositories the user has declared in their config.scm, or periodically
rsync’ing some files with a remote host.

> If people agree, I think we could aim for merging it in the next Guix
> release, which would leave us a few months.

To clarify, do you mean v1.3.0 or v1.4.0 (or whatever it’s going to be
called)?  IIUC v1.3.0 is going to be released in a few weeks (rc1 was
just announced), that might not be enough time for merging Guix Home as
the API for some of the core services are still subject to change.  WDYT
Andrew?

[1]: https://lists.sr.ht/~abcdw/rde-devel
[2]: https://github.com/nix-community/home-manager

Re: Add a way to disable serialization support to (guix services configuration)

[Xinglu Chen]

Hi,

On Fri, Apr 23 2021, Xinglu Chen wrote:

>> Wouldn’t it be nicer to write:
>>
>>   (define-configuration foo
>> (bar (integer 123) "doc" no-serializer)
>> (baz (string "") "doc"))
>>
>> where ‘bar’ wouldn’t have a serializer and ‘baz’ would?
>>
>> It’s also probably easier to implement correctly.
>
> I think that would be a good idea, maybe it could also make having a
> default value be optional, like this:
>
> #+begin_src scheme
> (define-configuration foo
>   (bar (integer) "doc" no-serializer) ;no default
>   (baz (string "default") "doc"))
> #+end_src

Since nobody seemed to show any objections, I went ahead and did
something like this myself (see the attached patches).  My macros skills
aren’t that good so I hope I didn’t make any obvious mistakes. :)

I haven’t tested it thoroughly, but at least it didn’t break anything
when I ran ‘./pre-inst-env guix home build ...’. :)

>From 231281ebf555295e83513873293a1ad3eab884a8 Mon Sep 17 00:00:00 2001
Message-Id: <231281ebf555295e83513873293a1ad3eab884a8.1619869705.git.pub...@yoctocell.xyz>
In-Reply-To: 
References: 
From: Xinglu Chen 
Date: Sat, 1 May 2021 13:24:43 +0200
Subject: [PATCH 1/2] services: configuration: Support fields without default
 values.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Not all fields in a configuration have a sensible default value,
e.g. ‘user.name’ in gitconfig, the user should have to set that themselves

* gnu/services/configuration.scm (configuration-missing-field): New procedure.
(define-configuration): Make default value optional.
---
 gnu/services/configuration.scm | 78 ++
 1 file changed, 51 insertions(+), 27 deletions(-)

diff --git a/gnu/services/configuration.scm b/gnu/services/configuration.scm
index 90f12a8d39..85e1ac78cb 100644
--- a/gnu/services/configuration.scm
+++ b/gnu/services/configuration.scm
@@ -2,6 +2,7 @@
 ;;; Copyright © 2015 Andy Wingo 
 ;;; Copyright © 2017 Mathieu Othacehe 
 ;;; Copyright © 2017, 2018 Clément Lassieur 
+;;; Copyright © 2021 Xinglu Chen 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -63,6 +64,9 @@
 (define (configuration-missing-field kind field)
   (configuration-error
(format #f "~a configuration missing required field ~a" kind field)))
+(define (configuration-no-default-value kind field)
+  (configuration-error
+   (format #f "`~a' in `~a' does not have a default value" kind field)))
 
 (define-record-type* 
   configuration-field make-configuration-field configuration-field?
@@ -112,7 +116,7 @@
 (define-syntax define-configuration
   (lambda (stx)
 (syntax-case stx ()
-  ((_ stem (field (field-type def) doc) ...)
+  ((_ stem (field (field-type properties ...) doc) ...)
(with-syntax (((field-getter ...)
   (map (lambda (field)
  (id #'stem #'stem #'- field))
@@ -121,36 +125,56 @@
   (map (lambda (type)
  (id #'stem type #'?))
#'(field-type ...)))
+ ((field-default ...)
+  (map (match-lambda
+ ((field-type default _ ...) default)
+ ;; We get warnings about `disabled' being an
+ ;; unbound variable unless we quote it.
+ (_ (syntax 'disabled)))
+   #'((field-type properties ...) ...)))
  ((field-serializer ...)
   (map (lambda (type)
  (id #'stem #'serialize- type))
#'(field-type ...
-   #`(begin
-   (define-record-type* #,(id #'stem #'< #'stem #'>)
- #,(id #'stem #'% #'stem)
- #,(id #'stem #'make- #'stem)
- #,(id #'stem #'stem #'?)
- (%location #,(id #'stem #'-location)
-(default (and=> (current-source-location)
-source-properties->location))
-(innate))
- (field field-getter (default def))
- ...)
-   (define #,(id #'stem #'stem #'-fields)
- (list (configuration-field
-(name 'field)
-(type 'field-type)
-(getter field-getter)
-(predicate field-predicate)
-(serializer field-serializer)
-(default-value-thunk (lambda () def))
-(documentation doc))
-   ...))
-   (define-syntax-rule (stem arg (... ...))
- (let ((conf (#,(id #'s

Re: Add a way to disable serialization support to (guix services configuration)

[Xinglu Chen]

Hi,

On Fri, Apr 23 2021, Ludovic Courtès wrote:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>>> +(define-syntax-rule (without-field-serialization definition)
>>> +  (syntax-parameterize ((configuration-field-serialization?
>>> + (identifier-syntax #f)))
>>> +definition
>>> +#t))
>>> +
>>> +(without-field-serialization
>>> +  (define-configuration foo
>>> +(bar (integer 123) "doc")))
>
> In hindsight, I find this syntax quite inelegant and suboptimal.
>
> Wouldn’t it be nicer to write:
>
>   (define-configuration foo
> (bar (integer 123) "doc" no-serializer)
> (baz (string "") "doc"))
>
> where ‘bar’ wouldn’t have a serializer and ‘baz’ would?
>
> It’s also probably easier to implement correctly.

I think that would be a good idea, maybe it could also make having a
default value be optional, like this:

#+begin_src scheme
(define-configuration foo
  (bar (integer) "doc" no-serializer) ;no default
  (baz (string "default") "doc"))
#+end_src

Maxim and I had a discussion about this[1].

[1]: https://yhetil.org/guix-devel/87k0ov7w72@yoctocell.xyz

Re: Best practices for writing services

[Xinglu Chen]

Hi,

On Fri, Apr 23 2021, Maxim Cournoyer wrote:

>> But the problem here is that it doesn’t force the user to configure the
>> field.  In a Git config for example, the user should be forced to set
>> ‘user.name’ and ‘user.email’, otherwise they can’t commit anything.  You
>> will just have to set the default value to ‘disabled’, like this:
>>
>> #+begin_src scheme
>> (define (serialize-string field-name val) ...)
>> (define-maybe string)
>> (define-configuration test-config
>>   (config
>> (maybe-string ’disabled))
>> "docs"")
>> #+end_src
>
> Ah, thanks for explaining, now I understand your point well.
>
> I've just tried something:
>
> --8<---cut here---start->8---
> (define-configuration test-config
>(name (string #f) "Your name"))
> scheme@(guile-user)> (test-config)
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> ERROR:
>   1. : "Invalid value for field name: #f"
>   2. 
> --8<---cut here---end--->8---
>
> So you could choose an invalid default value, which would force the user
> to specify it (else they'd get the not so obvious error message above).
> It should be improved too!  I'll see if I can do something.

That would be a workaround for now.  Thank you!

Re: Best practices for writing services

[Xinglu Chen]

On Wed, Apr 21 2021, Maxim Cournoyer wrote:

>> One thing that I find a little annoying is that you have to specify a
>> default value for the fields.  This doesn’t make much sense in some
>> cases, e.g. there is no good default value for ‘user.name = NAME’ in the
>> Git config, the user should have to specify that themselves.
>
> There's a 'define-maybe' that can be used to declare a field that can
> take more than one type, e.g.:
>
> (define-maybe string)
>
> Will generate a definition like so:
>
> --8<---cut here---start->8---
> (define (maybe-string? val)
>(or (eq? val 'disabled) (string? val)))
> --8<---cut here---end--->8---
>
> Which the validator of define-configuration will use if you specify a
> field with the type 'maybe-string'.
>
> 'disabled is a bit semantically broken in some cases ('unspecified'
> could be nicer), but it does the job.

But the problem here is that it doesn’t force the user to configure the
field.  In a Git config for example, the user should be forced to set
‘user.name’ and ‘user.email’, otherwise they can’t commit anything.  You
will just have to set the default value to ‘disabled’, like this:

#+begin_src scheme
(define (serialize-string field-name val) ...)
(define-maybe string)
(define-configuration test-config
  (config
(maybe-string ’disabled))
"docs"")
#+end_src

>> Another thing is that I don’t always want to “serialize-” the value for a
>> field, so I sometimes end up defining a bunch of dummy serializers that
>> just return an empty string.
>
> Good point!  I've tried addressing that, without success so far [0].

Cool, that would definitely be an improvement!

Re: Best practices for writing services

[Xinglu Chen]

On Thu, Apr 22 2021, raingloom wrote:

>> One thing that I find a little annoying is that you have to specify a
>> default value for the fields.
>
> Are you sure? If you don't specify a default, won't the user just be
> forced to write
> (service whatever
>   (whatever-configuration
>   (mandatory-field 'bleepbloop)))
>
> instead of the shorter (service whatever)?

If I write something like this

#+begin_src scheme
(use-modules (gnu services configuration))
(define (serialize-list field-name val) "")
(define-configuration test-config
  (config
   (list)
   "configuration for test"))
#+end_src

and evaluate it, I will get an error.  I have to specify a default value
for the ‘config’ field to make it work.

#+begin_src scheme
(use-modules (gnu services configuration))
(define (serialize-list field-name val) "")
(define-configuration test-config
  (config
   (list '())   ;default to '()
   "configuration for test"))
#+end_src

Re: Best practices for writing services

[Xinglu Chen]

Hi,

On Tue, Apr 20 2021, Maxim Cournoyer wrote:

> That's a very good question, which I asked myself recently when
> attempting to write my first non-trivial service for Guix
> (jami-daemon-service-type).  I'd say 'define-configuration' is
> technically superior because of the automatic type checking it provides.
> It's also neat to be able to define the doc at one place and
> auto-generate it (although that's still manual for now).

You mean that one has to manually evaluate the ‘generate-documentation’
sexp and paste the output of it in the manual?  I thought it would
automatically update the manual when running ‘make’. ;)

> It has definitely been collecting some dust compared to the simpler
> approach using 'define-record-type*' directly, and the doc output it
> can generate doesn't match what is currently the norm in the manual,
> so it'd need a bit of a refresh.

Yeah, I noticed that some sections in the manual looked a bit different
than the rest.

One thing that I find a little annoying is that you have to specify a
default value for the fields.  This doesn’t make much sense in some
cases, e.g. there is no good default value for ‘user.name = NAME’ in the
Git config, the user should have to specify that themselves.

Another thing is that I don’t always want to “serialize-” the value for a
field, so I sometimes end up defining a bunch of dummy serializers that
just return an empty string.

Re: A new wip-emacs branch

[Xinglu Chen]

On Tue, Apr 06 2021, Leo Prikler wrote:

>> FYI Geiser has recently been slit up into multiple packages with one
>> core Geiser package[1].  Should the Geiser package be updated in
>> wip-emacs or directly on master?
>> 
>> [1]: https://github.com/melpa/melpa/pull/7514
> That depends.  If geiser now uses an unaltered emacs-build-system it
> can go either way, but if it still has some special needs to take care
> of, updating it on wip-emacs will mean less work overall.

Looks like someone already sent a patch to update it[1]. :)

[1]: 
https://yhetil.org/guix-patches/byapr05mb4023349403c379ca3db8ab7dc5...@byapr05mb4023.namprd05.prod.outlook.com

Re: A new wip-emacs branch

[Xinglu Chen]

On Tue, Apr 06 2021, Leo Prikler wrote:

> There are still some packages, that use the old convention, e.g. emacs-
> geiser.

FYI Geiser has recently been slit up into multiple packages with one
core Geiser package[1].  Should the Geiser package be updated in
wip-emacs or directly on master?

[1]: https://github.com/melpa/melpa/pull/7514

Re: Security related tooling project

[Xinglu Chen]

On Sun, Apr 04 2021, Christopher Baines wrote:

> Cool :) While it's not directly security related, I really want the
> subscriptions functionality I'm planning to work on to be done so that
> people can subscribe to things related to the packages they use, like
> new versions becoming available, or the build breaking for example, as
> that might help people stay involved.

A bit off-topic, but I think it would be nice if the Emails/RSS feeds
would contain more information.  Right now it just says that PACKAGE on
ARCHITECTURE is fixed/broken, and gives a URL pointing to the build job.
I think it would be useful to also show the commit (the revision and
the commit summary for some context) that caused the fix/failure, and
maybe also the time it took to build the package, plus a link to the raw
build log.

All of this sounds very exciting.  Keep up the great work!

Re: A new wip-emacs branch

[Xinglu Chen]

On Sat, Apr 03 2021, Leo Prikler wrote:

> Your patch LGTM in a vaccum (except that package-version this-package
> could be abbreviated to just "version" IIUC), but I went for a
> different fix, since emacsql tried to avoid redundancies by putting in
> other redundancies.
>
> I ran a small test with emacs-emacsql-sqlite on
> 2be3daa19d2fd47933c622995d2f2dde714075e6, but please try it for
> yourself and check whether everything works as you expect it to.

Thanks for fixing the problem, but now I noticed that 'emacs-pdf-tools'
doesn't build.

--8<---cut here---start->8---
starting phase `emacs-add-source-to-load-path'
Backtrace:
   7 (primitive-load "/gnu/store/g7vcnpqrs3p76qm9xrnm1sz65ss…")
In ice-9/eval.scm:
   191:35  6 (_ _)
In guix/build/gnu-build-system.scm:
838:2  5 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
  1736:10  4 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
   857:16  3 (every1 # …)
In guix/build/gnu-build-system.scm:
   847:30  2 (_ _)
   847:30  1 (_ _)
In ice-9/boot-9.scm:
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
Wrong type to apply: #f
note: keeping build directory 
`/tmp/guix-build-emacs-pdf-tools-0.90-1.c510442.drv-0'
builder for 
`/gnu/store/d992q7cfb1wlfffg15g7bgsa32qjanrm-emacs-pdf-tools-0.90-1.c510442.drv'
 failed with exit code 1
build of 
/gnu/store/d992q7cfb1wlfffg15g7bgsa32qjanrm-emacs-pdf-tools-0.90-1.c510442.drv 
failed
View build log at 
'/var/log/guix/drvs/d9/92q7cfb1wlfffg15g7bgsa32qjanrm-emacs-pdf-tools-0.90-1.c510442.drv.bz2'.
guix build: error: build of 
`/gnu/store/d992q7cfb1wlfffg15g7bgsa32qjanrm-emacs-pdf-tools-0.90-1.c510442.drv'
 failed
--8<---cut here---end--->8---

The attached patch fixed the problem for me.

>From b49dd5be93bb5ba9630dca8d5bb142f258cb0781 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Xinglu Chen 
Date: Sun, 4 Apr 2021 11:28:04 +0200
Subject: [PATCH wip-emacs] gnu: emacs-pdf-tools: Adjust to changes in
 emacs-build-system.

* gnu/packages/emacs-xyz.scm (emacs-pdf-tools)[#:phases]: Rename
'add-source-to-load-path' to 'expand-load-path'.
---
 gnu/packages/emacs-xyz.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 0382cfdd17..9dbfce6f37 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -2920,7 +2920,7 @@ during idle time, while Emacs is doing nothing else.")
(emacs-substitute-variables "pdf-tools.el"
  ("pdf-tools-handle-upgrades" '()
(add-after 'emacs-patch-variables 'emacs-add-source-to-load-path
- (assoc-ref emacs:%standard-phases 'add-source-to-load-path))
+ (assoc-ref emacs:%standard-phases 'expand-load-path))
(add-after 'emacs-add-source-to-load-path 'emacs-install
  (assoc-ref emacs:%standard-phases 'install))
(add-after 'emacs-install 'emacs-build

base-commit: 2be3daa19d2fd47933c622995d2f2dde714075e6
-- 
2.31.1

Re: A new wip-emacs branch

[Xinglu Chen]

On Sat, Apr 03 2021, Xinglu Chen wrote:

> I tried the 'wip-emacs' branch (commit
> b18d605fcb51bcce56a1114f82645658db9f5b14), and I noticed that
> 'emacs-emacsql' was failing to install.  The 'make-autoloads' phase
> fails with:

I was able to fix this with the attached patch.

>From 59e3acc0bebe97e33c5ea557f40eddf6467cfff7 Mon Sep 17 00:00:00 2001
Message-Id: <59e3acc0bebe97e33c5ea557f40eddf6467cfff7.1617450934.git.pub...@yoctocell.xyz>
From: Xinglu Chen 
Date: Sat, 3 Apr 2021 13:52:05 +0200
Subject: [PATCH wip-emacs] gnu: emacs-emacsql: Adjust to changes in
 emacs-build-system.

* gnu/packages/emacs-xyz.scm (emacs-emacsql)[#:phases]: Update install
directory for bytecompiled Emacs Lisp files.
---
 gnu/packages/emacs-xyz.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 0bd7fe8f27..cd0138663f 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -15529,7 +15529,9 @@ object has been freed.")
(install-file "sqlite/emacsql-sqlite"
  (string-append out "/bin"))
(for-each (cut install-file <>
-  (string-append out "/share/emacs/site-lisp"))
+  (string-append out
+ "/share/emacs/site-lisp/emacsql-"
+ ,(package-version this-package)))
  (find-files "." "\\.elc*$")))
  #t)
 (inputs

base-commit: b18d605fcb51bcce56a1114f82645658db9f5b14
-- 
2.31.1

Re: A new wip-emacs branch

[Xinglu Chen]

On Thu, Apr 01 2021, Leo Prikler wrote:

Hi,

I tried the 'wip-emacs' branch (commit
b18d605fcb51bcce56a1114f82645658db9f5b14), and I noticed that
'emacs-emacsql' was failing to install.  The 'make-autoloads' phase
fails with:

--8<---cut here---start->8---
starting phase `make-autoloads'
Opening directory: No such file or directory, 
/gnu/store/1bylpqrx1da96z3zc7s81sx78c89xccs-emacs-emacsql-3.0.0/share/emacs/site-lisp/emacsql-3.0.0
command 
"/gnu/store/70n63hq48ycj7sch0b6wmr6928hw10ig-emacs-minimal-27.2/bin/emacs" 
"--quick" "--batch" "--eval=(eval '(let ((backup-inhibited t) 
(generated-autoload-file 
\"/gnu/store/1bylpqrx1da96z3zc7s81sx78c89xccs-emacs-emacsql-3.0.0/share/emacs/site-lisp/emacsql-3.0.0/emacsql-autoloads.el\"))
 (update-directory-autoloads 
\"/gnu/store/1bylpqrx1da96z3zc7s81sx78c89xccs-emacs-emacsql-3.0.0/share/emacs/site-lisp/emacsql-3.0.0\"))
 nil)" failed with status 255
builder for 
`/gnu/store/wfrm2qwyl0kj3ip0rfplbgx6f8nc39vs-emacs-emacsql-3.0.0.drv' failed 
with exit code 1
build of /gnu/store/wfrm2qwyl0kj3ip0rfplbgx6f8nc39vs-emacs-emacsql-3.0.0.drv 
failed
View build log at 
'/var/log/guix/drvs/wf/rm2qwyl0kj3ip0rfplbgx6f8nc39vs-emacs-emacsql-3.0.0.drv.bz2'.
guix build: error: build of 
`/gnu/store/wfrm2qwyl0kj3ip0rfplbgx6f8nc39vs-emacs-emacsql-3.0.0.drv' failed
--8<---cut here---end--->8---

I can only find
'/gnu/store/1bylpqrx1da96z3zc7s81sx78c89xccs-emacs-emacsql-3.0.0/share/emacs/site-lisp/emacs',
there is no 'emacsql-3.0.0' directory.

Any ideas?

Re: Release 1.2.1: Cuirass failed to build Haskell 179 packages

[Xinglu Chen]

On Tue, Mar 23 2021, zimoun wrote:

> Hi,
>
> On Tue, 23 Mar 2021 at 11:32, Xinglu Chen  wrote:
>
>>> And if someone is in the mood to check why ghc-haddock is broken. :-)
>>
>> This was an issue with upstream[1], it has since been fixed but the
>> releases that include the fix are only built for GHC 8.8 or later.
>
> Thanks!  Much appreciated.

You are welcome!

>> Maybe its time to update to a newer Stackage LTS release? :)
>
> Well, I do not know if it possible to do so before the next release.
> IMHO, let focus on what remains for the next release and let upgrade the
> Stackage LTS after.

Ok, sounds good to me.

Re: Release 1.2.1: Cuirass failed to build Haskell 179 packages

[Xinglu Chen]

On Wed, Mar 10 2021, zimoun wrote:

> Using the command “guix weather --display-missing” at commit 6bed29b, I
> identify 180 packages ghc-* which are missing.  Then I locally rebuild
> all of them and they build successfully.  The only one broken is:
>
>   ghc-haddock
>
> Therefore, is it possible to “restart” the build on Cuirass of these 179
> ghc-* packages?  It could be nice to have substitutes for the next
> release.
>
> And if someone is in the mood to check why ghc-haddock is broken. :-)

This was an issue with upstream[1], it has since been fixed but the
releases that include the fix are only built for GHC 8.8 or later.

Maybe its time to update to a newer Stackage LTS release? :)

[1]: https://github.com/haskell/haddock/issues/850

Re: Best practices for writing services

[Xinglu Chen]

On Fri, Mar 19 2021, Joshua Branson wrote:

>> Currently there seems to be two main ways to do this, the first one
>> is the define one or more records for the configuration field of a
>> service using `define-record-type*`, see the tor service in (gnu
>> services networking) for example.  The other method is to use
>> `define-configuration` to declare the configuration fields of a service,
>> see the transmission service in (gnu services file-sharing) for example.
>
> I believe that the first method via define-record-type* seems to be the
> recommended method to do this.  I only say that because I feel like more
> services are defined that way now.  :)

I decided to use `define-record-type*` since the service for mcron is
pretty simple because it is already configured in Guile. :)

> I've been working on a sway service and an endlessh service in my
> hacking videos
> (https://video.hardlimit.com/accounts/joshua_branson/video-channels).

Cool, great to see more videos on Guix, and it's on PeerTube.

> I was running into issues, where I could compile the service, but
> trying to reconfigure my system would result in errors.

The Guile compiler seems to miss quite a few errors in my exprience too.

> The errors messages were a little vague.  I will also say that the
> better method I have found in writing a guix service is to
>
> 1) write the service as simply as possible first.  I personally would
> copy the simplest service that you can find in gnu/services/  and modify
> that via a M-x anzu-query-replace-regexp.  If re-configuring works, make a 
> commit.
>
> 2) If possible, containerize the service.  If it works, make a commit.
>
> 3) Now start adding in all the features you left out before.

Thanks for the suggestions, I will take them into account in the future.

Best practices for writing services

[Xinglu Chen]

Hi Guix,

I am going to write an mcron service for `guix home`[1][2] and before
proceding, I would like to get some suggestions on what the best
practices are for writing services in Guix.

Currently there seems to be two main ways to do this, the first one
is the define one or more records for the configuration field of a
service using `define-record-type*`, see the tor service in (gnu
services networking) for example.  The other method is to use
`define-configuration` to declare the configuration fields of a service,
see the transmission service in (gnu services file-sharing) for example.

The first method seems to be the more common one but the developer
usually has to write a lot of things manually.  The "real" configuration
file for the program or is usually created by concatenating a bunch of
strings and the developer has to write documentation for all the
configuration fields manually.

The second method removes quite a lot of boilerplate and the developer
will define different serializers that convert scheme syntax like lists,
alist, boolean... to the "real" configuration syntax of the program.  It
also does some automatic typechecking to some degree and allows the
developer to write docstrings for each configuration field.  There is
then a procedure called `generate-documentation` which can automatically
generate texinfo documenation from the docstrings.

I couldn't find any information in the manual regarding what conventions
should be used when writing services for Guix and would like to hear
from more experienced Guix hackers what the best practices are.

[1]: https://yhetil.org/guix-devel/878s6u2pco@trop.in
[2]: https://lists.sr.ht/~abcdw/rde-devel/%3C87h7l9r9xm.fsf%40yoctocell.xyz%3E

Using package transformations declaratively (was: [bug#47163] [PATCH] refresh: Add '--installed' option.)

[Xinglu Chen]

On Tue, Mar 16 2021, Ludovic Courtès wrote:

> You may also like the new ‘--with-latest’ package transformation
> option.  :-)

I really like package transformations but is there a way to use specify
them with Guile so I can use them with `guix home`[1] or in manifests?

Ccing guix-devel

[1]: https://yhetil.org/guix-devel/878s6u2pco@trop.in

Re: [bug#47163] Using package transformations declaratively (was: [bug#47163] [PATCH] refresh: Add '--installed' option.)

[Xinglu Chen]

On Tue, Mar 16 2021, zimoun wrote:

>> I really like package transformations but is there a way to use specify
>> them with Guile so I can use them with `guix home`[1] or in manifests?
>
> There is several ways to have package transformations at the manifest
> level.  One is:
>
> --8<---cut here---start->8---
> (use-modules (guix transformations))
>
> (define transform1
>   (options->transformation
> '((with-c-toolchain . "hello=gcc-toolchain@8"
>
> (packages->manifest
>   (list (transform1 (specification->package "hello"
> --8<---cut here---end--->8---

Cool, thanks for the help.