catonano@gmail.com writes:
I asked for indications about the process (what magic to use in the
REPL)
My experience with Guix, in general, is that the REPL isn't
particularly useful for any task beyond very simple testing (eg, what
are the contents of ‘%base-services’). It's a shame, but I suspect
it's like this because it's hard to make it more functional, and there
are more important problems to work on. Even though I would much
prefer to do almost all work with a REPL, I have not invested the
effort into figuring it out because I don't have the time or
expertise, currently. I can't fault anyone else for making similar
choices.
This should be covered in the cookbook
I agree. The cookbook could use a lot of work. Guix's documentation
suffers in the middle ranges. There's a lot of very high level
overview, and all the low level bits are reasonably documented, but
there's very little on how to integrate them.
If we were building a house, it'd be like having instructions that
say: our house is made out of rooms. Then being given a bill of
materials for all the different types of nails, boards, etc that can
be used to build a house. There's no (or almost no) instructions for
how to use those parts to build the shepherd service room, or how to
connect the activation plumbing, etc. Unfortunately, those are the
instructions that are most important, I think.
In fact Tryton modules are not python modules and there's a patch
modifying how Tryton retrieves its modules in Guix
Yet there's no service for Tryton
This is the case for many packages. The good news(?) is that you can
create your services your operating system config, and if you can get
them working acceptably, send a patch.
I think the friction on how to write a service is not in the semantics
involved
It's more menial
See above: there's no documentation for assembly. Everything I've
learned was from studying the source.
As I'm writing this, I noticed someone replied to my toot
(here
https://tines.spork.org/objects/a2ff7376-c9a2-4bbd-9307-a5374571edb4 )
as you can see, they also noticed a difference in the experience
between creating home services and system services
I wasn't following this thread at the time, and didn't know whether
you were talking about shepherd services or not. In terms of shepherd
services, yes, there's quite a difference (maybe it would be a good
idea to define a generic service type, akin to
‘home-shepherd-service-type’ that only extends the
‘shepherd-root-service-type’ with a shepherd service?). As I said
there, if you have questions, feel free to ask! I may not be able to
write the cookbook/how-to that I want to, but I can try to answer
questions and share what little knowledge I do have with a fellow
neophyte.
However, for the types of services you'd add to the ‘services’ slot of
the home/operating-system config, I don't think there is much of a
difference; or maybe none at all.
Guix is being successful, these days but that's an exception in the
free software world and more so in the GNU world
I'm happy that Guix is growing, and more people are using it and
adding to it (I'm a recent adopter, too!). But I think it's still a
niche distribution, and it shows in things like the documentation, the
builds breaking, old or broken packages, etc.
I want to be very clear on this point, though: I don't blame anyone
for this, and I don't mean to downplay anyone's work because of these
problems. Creating and maintaining a distribution, especially one as
different as Guix, is a tremendous amount of work, and it's frankly
incredible how well Guix does on such a small core crew. It's simply
impossible to have the same level of polish as a bigger, more
established distribution, with an order of magnitude (or more)
contributors.
I have a job now (and it has to do with Odoo), I also train in a gym,
I
like to spend the free time I have on the beach (as it's evident from
my presence on the fediverse) so I don't know it's not like I have
any
slots to assign to attempt this
We're, all of us, in a similar situation, and we're few in number
(relatively), with a lot of work to do. I think this explains the
state of Guix more than anything else.
-bjc