Re: Formalizing teams
December 23, 2021 4:13 PM, "Blake Shaw" wrote: > Ludovic Courtès writes: > >> One idea that I like is to bring structure to the group, or rather to >> make structure visible, so that newcomers know who they can talk to to >> get started on a topic, know who to ping for reviews, and so that each >> one of us can see where they fit. Rust has well-defined teams: >> >> https://www.rust-lang.org/governance > > Definitely! Perhaps this an aesthetic matter, but keeping-with the > community spirit of Guix, and the existing nomenclature where the > 'core' maintainers are called a "collective", perhaps we should avoid > some of the more corporate "team" language of Rust/Mozilla and stick to > "collectives"? > I reckon 'coterie' is more elegant a term: ``` : an intimate and often exclusive group of persons with a unifying common interest or purpose ``` Jonathan McHugh indieterminacy@libre.brussels
search-input-file vs (assoc-ref inputs)
I noticed that, as part of the transition to the new inputs style [0], we are sometimes replacing code like (assoc-ref inputs "foo") with (search-input-file inputs "/bin/foo"). I think that we should instead replace the old style with gexps that specify which package, in order to keep the equivalent functionality. Otherwise, we risk regressions, when the code finds a match for the desired filename in the wrong input. I would say that (search-input-file) is a replacement for the Guile (which) procedure. On the other hand, we can replace (assoc-ref inputs ...) with (this-package-input "foo"). What do you think? [0] https://guix.gnu.org/en/blog/2021/the-big-change/
Re: Formalizing teams
Ludovic Courtès writes: > One idea that I like is to bring structure to the group, or rather to > make structure visible, so that newcomers know who they can talk to to > get started on a topic, know who to ping for reviews, and so that each > one of us can see where they fit. Rust has well-defined teams: > > https://www.rust-lang.org/governance > Definitely! Perhaps this an aesthetic matter, but keeping-with the community spirit of Guix, and the existing nomenclature where the 'core' maintainers are called a "collective", perhaps we should avoid some of the more corporate "team" language of Rust/Mozilla and stick to "collectives"? > In Rust, teams are responsible for overseeing discussions and changes in > their area, but also ultimately for making decisions. I think that’s > pretty much the case with the informal teams that exist today in Guix, > but that responsibility could be made more explicit here. They > distinguish teams from “working groups”, where working groups work on > actually implementing what the team decided. > > How about starting with a web page listing these teams, their work, > their members, and ways to contact them? Teams would be the primary > contact point and for things that fall into their area and would be > responsible for channeling proposals and advancing issues in their area. > > What do people think? I think it sounds great. The question remains what is the medium-space where through which the teams interact? How do we prevent teams from becoming silo'd off from one another? Do we have an "assembly" or an "assembler"? Should this become a matter for Guix Days? -- “In girum imus nocte et consumimur igni”
[PATCH v2] doc: Add Writing Service Configuration section.
* guix.texi (Writing Service Configuration): New section.
---
doc/guix.texi | 252 +-
1 file changed, 248 insertions(+), 4 deletions(-)
diff --git a/doc/guix.texi b/doc/guix.texi
index 333cb4117a..29d85d3dc5 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -10363,6 +10363,7 @@ compiling modules. It can be @code{#f}, @code{#t}, or
@code{'detailed}.
The other arguments are as for @code{derivation} (@pxref{Derivations}).
@end deffn
+@anchor{file-like objects}
@cindex file-like objects
The @code{local-file}, @code{plain-file}, @code{computed-file},
@code{program-file}, and @code{scheme-file} procedures below return
@@ -15942,6 +15943,7 @@ symlink:
Return a service that sets the host name to @var{name}.
@end deffn
+@anchor{console-font-service-type}
@defvr {Scheme Variable} console-font-service-type
Install the given fonts on the specified ttys (fonts are per
virtual console on the kernel Linux). The value of this service is a list of
@@ -33717,6 +33719,7 @@ a daemon that can execute application bundles
(sometimes referred to as
@end defvr
+@anchor{docker-configuration}
@deftp {Data Type} docker-configuration
This is the data type representing the configuration of Docker and Containerd.
@@ -35652,10 +35655,11 @@ them in an @code{operating-system} declaration. But
how do we define
them in the first place? And what is a service anyway?
@menu
-* Service Composition:: The model for composing services.
-* Service Types and Services:: Types and services.
-* Service Reference:: API reference.
-* Shepherd Services:: A particular type of service.
+* Service Composition::The model for composing services.
+* Service Types and Services:: Types and services.
+* Writing Service Configurations:: A guideline for writing guix services.
+* Service Reference:: API reference.
+* Shepherd Services:: A particular type of service.
@end menu
@node Service Composition
@@ -35851,6 +35855,245 @@ There can be only one instance of an extensible
service type such as
Still here? The next section provides a reference of the programming
interface for services.
+@node Writing Service Configurations
+@subsection Writing Service Configurations
+
+Guix already contains a wide variety of system and home services, but
+sometimes users might want to add new services. This section contains
+tips for simplifying this process, and should help to make service
+configurations and their implementations more consistent.
+
+@quotation Note
+If you find any exceptions or patterns missing in this section, please
+send a patch with additions/changes to @email{guix-devel@@gnu.org}
+mailing list or just start a discussion/ask a question.
+@end quotation
+
+@subsubheading Configuration Itself
+
+As we know from previous sections, a Guix service can accept a service
+value, usually some kind of configuration record and optionally, be
+extended with additional values by other services (@pxref{Service
+Composition}).
+
+When being extended, most services take some kind of configuration
+record or a list thereof, but in some cases a simpler value is all
+that is necessary.
+
+There are some cases, when the service accepts a list of pairs or some
+other non-record values. For example, @code{console-font-service-type}
+(@pxref{console-font-service-type}) accepts an
+association list, and @code{etc-service-type} (@pxref{etc-service-type})
+accepts a list of lists. Those services are kinda special, they do
+auxiliary work of setting up some part of the operating system or home
+environment, or just an intermediate helpers used by other Guix
+services. For example @code{etc-service-type} is not that useful on its
+own, but it helps other services to create files in /etc directory, when
+it necessary.
+
+However, in most cases a Guix service is wrapping some software, which
+consists of one or more packages, and configuration file or files.
+Therefore, the value for such service is quite complicated and it's hard
+to represent it with just a list or basic data type, in such cases we
+use a record. Each such record (@pxref{SRFI-9 Records, Scheme Records,,
+guile, GNU Guile Reference Manual}) have @samp{-configuration} suffix,
+for example, the @code{docker-service-type} should accept a record type
+named @code{docker-configuration}, which contains fields used to
+configure Docker. Configuration records for home services should also
+have a @code{home-} prefix in their name.
+
+There is a module @code{gnu service configuration}, which contains
+helpers simplifying configuration definition process. Take a look at
+@code{gnu services docker} module or grep for
+@code{define-configuration} to find usage examples.
+
+@c Provide some examples, tips, and rationale behind @code{gnu service
+@c configuration} module.
+
+After a configuration record has been properly named and defined let's
+discuss how to name
Re: [RFC PATCH] doc: Add Writing Service Configuration section.
On 2021-12-22 09:53, Xinglu Chen wrote:
> Am Dienstag, der 21. Dezember 2021, um 13:21 +032, schrieb Andrew Tropin
> :
>
>> * guix.texi (Writing Service Configuration): New section.
>> ---
>> After reading the source code of different system services and implementing a
>> few of home services I decided to write down most important tips for
>> implementing guix service configurations. I belive having such a guideline
>> can simplify the development of new services and configurations for them, as
>> well as keeping those implementations consistent, which will simplify the
>> life
>> for users too because they won't need to learn a different configuration
>> approaches for different services.
>>
>> This section is not a final document, but a starting point for discussion and
>> further extension of the guideline. Feel free to raise a question, point to
>> a
>> mistake, make a suggestion or propose an idea.
>
> Thanks for working on this! I left some comments and thoughts as I read
> through it (Warning, these is quite a lot :-)).
>
>> doc/guix.texi | 209 +-
>> 1 file changed, 205 insertions(+), 4 deletions(-)
>>
>> diff --git a/doc/guix.texi b/doc/guix.texi
>> index 333cb4117a..a48fb0e2b7 100644
>> --- a/doc/guix.texi
>> +++ b/doc/guix.texi
>> @@ -35652,10 +35652,11 @@ them in an @code{operating-system} declaration.
>> But how do we define
>> them in the first place? And what is a service anyway?
>>
>> @menu
>> -* Service Composition:: The model for composing services.
>> -* Service Types and Services:: Types and services.
>> -* Service Reference:: API reference.
>> -* Shepherd Services:: A particular type of service.
>> +* Service Composition::The model for composing services.
>> +* Service Types and Services:: Types and services.
>> +* Service Reference:: API reference.
>> +* Shepherd Services:: A particular type of service.
>> +* Writing Service Configurations:: A guideline for writing guix services.
>> @end menu
>>
>> @node Service Composition
>> @@ -35851,6 +35852,206 @@ There can be only one instance of an extensible
>> service type such as
>> Still here? The next section provides a reference of the programming
>> interface for services.
>>
>> +@node Writing Service Configurations
>> +@subsection Writing Service Configurations
>
> The TOC menu says that “Writing Services Configurations” comes after
> “Shepherd Services”, but this doesn’t seem to be the case here.
>
Done.
>> +There are a lot of system and home services already written, but from
>> +time to time it's necessary to write one more.
>
> I would write something like
>
> Guix already contains a wide variety of system and home services, but
> sometimes users might want to add new services.
>
>> +This section contains
>> +tips for simplifying this process, and should help to make service
>> +configurations and their implementations more consistent.
>> +
>> +@quotation Note
>> +If you find any exceptions or patterns missing in this section, please
>> +send a patch with additions/changes to @email{guix-devel@@gnu.org}
>> +mailing list or just start a discussion/ask a question.
>> +@end quotation
>
> I don’t think this note is really necessary; there is already a section
> on contributing to the project, see “17 Contributing”.
>
Not necessary, but I would keep it for a few months to make people more
involved in the polishing of this guide.
>> +@subsubheading Configuration Itself
>> +
>> +As we know from previous section a guix service can accept a value and
>^ missing comma
> s/section/sections/
> s/guix/Guix
Done.
>
> When you say “service”, you mean a “service type”, right? Just “value”
> sounds a bit vague, maybe
I mean service, which is instantiated from some service type.
>
> … a value, usually some kind of configuration
> record (@pxref{RELEVANT NODE(s)})
changed it to service value and added this note.
>
> ?
>
>> +be extended with additional values by other services.
>
> Not all services are extendable though, to avoid ambiguity, maybe
>
> …, and optionally, be extended with additional configurations by other
> services (@pxref{Service Composition}).
>
Done.
>> +There are some
>> +cases, when the service accepts a list of pairs or some other values for
>
> I suggest:
>
> When being extended, most services take some kind of configuration
> 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
>
Re: Convention for new “guix style“?
indieterminacy@libre.brussels writes: > I wonder if there has been any progress made by Arun Isaac with his program, > Semantically meaningful S-expression diff > > https://archive.fosdem.org/2021/schedule/event/sexpressiondiff/ There’s also ydiff[1]. Unfortunately, it only produces an HTML file as output, so it cannot be used as a diff program with git. [1]: https://github.com/yinwang0/ydiff -- Ricardo
