how to create and test a new service definition

how to create and test a new service definition

[Vincent Legoll]

Hello,

I want to define a new shepherd service, I've read the doc
and wonder how I can test my new code. Is this documented
somewhere ?

I'm on guixsd in a qemu VM.

Thanks

-- 
Vincent Legoll

Re: how to create and test a new service definition

[Ludovic Courtès]

Hello,

Vincent Legoll <vincent.legoll@gmail.com> skribis:

> I want to define a new shepherd service, I've read the doc
> and wonder how I can test my new code. Is this documented
> somewhere ?

The best way to test your code is to write an ‘operating-system’
declaration that uses the new service and to instantiate it in a VM with
‘guix system vm’.

Once you’ve done that, you can also write an automated test for the new
service; see <https://gnu.org/s/guix/news/guixsd-system-tests.html>.

HTH!

Ludo’.

Re: how to create and test a new service definition

[Vincent Legoll]

> The best way to test your code is to write an ‘operating-system’
> declaration that uses the new service and to instantiate it in a VM with
> ‘guix system vm’.

Should that be working properly (out-of-the-box) when you're already in
a qemu VM (recursive virtualization) ?

I ask because I'm getting:

[...]
ERROR: qemu failed "qemu-system-x86_64"
[...]

> Once you’ve done that, you can also write an automated test for the new
> service; see <https://gnu.org/s/guix/news/guixsd-system-tests.html>.

I'm far from there, I have a *really* hard time getting back to guixsd. For
instance it took me very long time to find back the GUIX_PACKAGE_PATH
env var. This looks under-documented, or I don't understand how one is to
work on custom or new packages, etc...

guix edit is throwing me :
E166: Can't open linked file for writing

Looks like I'm missing something big.

-- 
Vincent Legoll

Re: how to create and test a new service definition

[Ludovic Courtès]

Vincent Legoll <vincent.legoll@gmail.com> skribis:

>> The best way to test your code is to write an ‘operating-system’
>> declaration that uses the new service and to instantiate it in a VM with
>> ‘guix system vm’.
>
> Should that be working properly (out-of-the-box) when you're already in
> a qemu VM (recursive virtualization) ?
>
> I ask because I'm getting:
>
> [...]
> ERROR: qemu failed "qemu-system-x86_64"

What were the lines above this one?  This tool tries to use KVM if it
seems available.  Maybe in your case it “seems” to be available (as in
/dev/kvm exists) but is actually unusable?

>> Once you’ve done that, you can also write an automated test for the new
>> service; see <https://gnu.org/s/guix/news/guixsd-system-tests.html>.
>
> I'm far from there, I have a *really* hard time getting back to guixsd. For
> instance it took me very long time to find back the GUIX_PACKAGE_PATH
> env var. This looks under-documented, or I don't understand how one is to
> work on custom or new packages, etc...

‘GUIX_PACKAGE_PATH’ is documented at
<https://www.gnu.org/software/guix/manual/html_node/Package-Modules.html#index-GUIX_005fPACKAGE_005fPATH>.

The workflow for defining packages is described at
<https://www.gnu.org/software/guix/manual/html_node/Defining-Packages.html>,
and that for contributing them is at
<https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html>.

There’s probably room for improvement though.  What changes/additions
would you suggest?

> guix edit is throwing me :
> E166: Can't open linked file for writing

This error does not come from ‘guix edit’, but maybe from your editor.
As for why the file is read-only, see
<https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-edit.html>.

HTH,
Ludo’.

Re: how to create and test a new service definition

[Catonano]

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

2017-05-13 22:06 GMT+02:00 Ludovic Courtès <ludo@gnu.org>:

> Vincent Legoll <vincent.legoll@gmail.com> skribis:
>
> >> The best way to test your code is to write an ‘operating-system’
> >> declaration that uses the new service and to instantiate it in a VM with
> >> ‘guix system vm’.
> >
> > Should that be working properly (out-of-the-box) when you're already in
> > a qemu VM (recursive virtualization) ?
> >
> > I ask because I'm getting:
> >
> > [...]
> > ERROR: qemu failed "qemu-system-x86_64"
>
> What were the lines above this one?  This tool tries to use KVM if it
> seems available.  Maybe in your case it “seems” to be available (as in
> /dev/kvm exists) but is actually unusable?
>
> >> Once you’ve done that, you can also write an automated test for the new
> >> service; see <https://gnu.org/s/guix/news/guixsd-system-tests.html>.
> >
> > I'm far from there, I have a *really* hard time getting back to guixsd.
> For
> > instance it took me very long time to find back the GUIX_PACKAGE_PATH
> > env var. This looks under-documented, or I don't understand how one is to
> > work on custom or new packages, etc...
>
> ‘GUIX_PACKAGE_PATH’ is documented at
> <https://www.gnu.org/software/guix/manual/html_node/Package-
> Modules.html#index-GUIX_005fPACKAGE_005fPATH>.
>
> The workflow for defining packages is described at
> <https://www.gnu.org/software/guix/manual/html_node/Defining-Packages.html
> >,
> and that for contributing them is at
> <https://www.gnu.org/software/guix/manual/html_node/
> Submitting-Patches.html>.
>
> There’s probably room for improvement though.  What changes/additions
> would you suggest?
>

Let me chime in here: I'd suggest to state the workflow or defining
services, as the one or deining packages is stated

But I'm not thinking about how to define and use The scheme structures. The
examples are enough for that.

I'm thinking about things like how to deal with qemu, if you want to test
your services in a vm

Is there any other way to get your feet wet with services ?

George suggested me the trick to link a checked out master branch to
.local/guix/profile (or maybe it's the other way around: it's liinking
.local/guix/profile to a checked out master branch)

Is anyone using this to work on services ? How, exactly ?

Thanks

[-- Attachment #2: Type: text/html, Size: 3609 bytes --]

Re: how to create and test a new service definition

[ng0]

On Sun, 14 May 2017, Catonano wrote:

> 2017-05-13 22:06 GMT+02:00 Ludovic Courtès <ludo@gnu.org>:
>
>> Vincent Legoll <vincent.legoll@gmail.com> skribis:
>>
>>>> The best way to test your code is to write an ‘operating-system’
>>>> declaration that uses the new service and to instantiate it in a VM with
>>>> ‘guix system vm’.
>>>
>>> Should that be working properly (out-of-the-box) when you're already in
>>> a qemu VM (recursive virtualization) ?
>>>
>>> I ask because I'm getting:
>>>
>>> [...]
>>> ERROR: qemu failed "qemu-system-x86_64"
>>
>> What were the lines above this one?  This tool tries to use KVM if it
>> seems available.  Maybe in your case it “seems” to be available (as in
>> /dev/kvm exists) but is actually unusable?
>>
>>>> Once you’ve done that, you can also write an automated test for the new
>>>> service; see <https://gnu.org/s/guix/news/guixsd-system-tests.html>.
>>>
>>> I'm far from there, I have a *really* hard time getting back to guixsd.
>> For
>>> instance it took me very long time to find back the GUIX_PACKAGE_PATH
>>> env var. This looks under-documented, or I don't understand how one is to
>>> work on custom or new packages, etc...
>>
>> ‘GUIX_PACKAGE_PATH’ is documented at
>> <https://www.gnu.org/software/guix/manual/html_node/Package-
>> Modules.html#index-GUIX_005fPACKAGE_005fPATH>.
>>
>> The workflow for defining packages is described at
>> <https://www.gnu.org/software/guix/manual/html_node/Defining-Packages.html
>>> ,
>> and that for contributing them is at
>> <https://www.gnu.org/software/guix/manual/html_node/
>> Submitting-Patches.html>.
>>
>> There’s probably room for improvement though.  What changes/additions
>> would you suggest?
>>
>
> Let me chime in here: I'd suggest to state the workflow or defining
> services, as the one or deining packages is stated
>
> But I'm not thinking about how to define and use The scheme structures. The
> examples are enough for that.
>
> I'm thinking about things like how to deal with qemu, if you want to test
> your services in a vm
>
> Is there any other way to get your feet wet with services ?
>
> George suggested me the trick to link a checked out master branch to
> .local/guix/profile (or maybe it's the other way around: it's liinking
> .local/guix/profile to a checked out master branch)
>
> Is anyone using this to work on services ? How, exactly ?
>
> Thanks
>

My current way of testing services is usually on bare-metal.
I had bad experiences with one network based service (gnunet)
and it being terrible to debug, so I took the QEMU out of there.
I test things this way which will not break my current generation 
like darkhttpd or the gopherd I submitted as a question.
Other, potential boot breaking, stuff I test on other systems.

This is also because I never really figured out the best way
to run network based services in qemu in Guix. I have no issues
with qemu, but on Guix many months back it behaved unlike the
qemu I knew from Gentoo.

There is lots of room for services in the documentation.
There should be a "contributing services" section in chapter 8,
currently I learn this the way I learned to do packages, by
repetition and failure until I see how to debug stuff.. which is already 
helping since I am starting to see patterns for debugging with darkhttpd 
(it helped that it simply worked and then randomly broke in further 
attempts).

Re: how to create and test a new service definition

[ng0]

On Sun, 14 May 2017, ng0 wrote:

> On Sun, 14 May 2017, Catonano wrote:
>
>>  2017-05-13 22:06 GMT+02:00 Ludovic Courtès <ludo@gnu.org>:
>>
>>>  Vincent Legoll <vincent.legoll@gmail.com> skribis:
>>>
>>>>>  The best way to test your code is to write an ‘operating-system’
>>>>>  declaration that uses the new service and to instantiate it in a VM
>>>>>  with
>>>>>  ‘guix system vm’.
>>>>
>>>>  Should that be working properly (out-of-the-box) when you're already in
>>>>  a qemu VM (recursive virtualization) ?
>>>>
>>>>  I ask because I'm getting:
>>>>
>>>>  [...]
>>>>  ERROR: qemu failed "qemu-system-x86_64"
>>>
>>>  What were the lines above this one?  This tool tries to use KVM if it
>>>  seems available.  Maybe in your case it “seems” to be available (as in
>>>  /dev/kvm exists) but is actually unusable?
>>>
>>>>>  Once you’ve done that, you can also write an automated test for the new
>>>>>  service; see <https://gnu.org/s/guix/news/guixsd-system-tests.html>.
>>>>
>>>>  I'm far from there, I have a *really* hard time getting back to guixsd.
>>>  For
>>>>  instance it took me very long time to find back the GUIX_PACKAGE_PATH
>>>>  env var. This looks under-documented, or I don't understand how one is
>>>>  to
>>>>  work on custom or new packages, etc...
>>>
>>>  ‘GUIX_PACKAGE_PATH’ is documented at
>>>  <https://www.gnu.org/software/guix/manual/html_node/Package-
>>>  Modules.html#index-GUIX_005fPACKAGE_005fPATH>.
>>>
>>>  The workflow for defining packages is described at
>>>  <https://www.gnu.org/software/guix/manual/html_node/Defining-Packages.html
>>>>  ,
>>>  and that for contributing them is at
>>>  <https://www.gnu.org/software/guix/manual/html_node/
>>>  Submitting-Patches.html>.
>>>
>>>  There’s probably room for improvement though.  What changes/additions
>>>  would you suggest?
>>> 
>>
>>  Let me chime in here: I'd suggest to state the workflow or defining
>>  services, as the one or deining packages is stated
>>
>>  But I'm not thinking about how to define and use The scheme structures.
>>  The
>>  examples are enough for that.
>>
>>  I'm thinking about things like how to deal with qemu, if you want to test
>>  your services in a vm
>>
>>  Is there any other way to get your feet wet with services ?
>>
>>  George suggested me the trick to link a checked out master branch to
>>  .local/guix/profile (or maybe it's the other way around: it's liinking
>>  .local/guix/profile to a checked out master branch)
>>
>>  Is anyone using this to work on services ? How, exactly ?
>>
>>  Thanks
>> 
>
> My current way of testing services is usually on bare-metal.
> I had bad experiences with one network based service (gnunet)
> and it being terrible to debug, so I took the QEMU out of there.
> I test things this way which will not break my current generation like 
> darkhttpd or the gopherd I submitted as a question.
> Other, potential boot breaking, stuff I test on other systems.
>
> This is also because I never really figured out the best way
> to run network based services in qemu in Guix. I have no issues
> with qemu, but on Guix many months back it behaved unlike the
> qemu I knew from Gentoo.

I have to append to this: I tried debugging darkhttpd with a shared VM
now and it is much more useful to get a bourne-like shell than
a frozen system if you make a syntax error in the container description.

So that's definitely a plus for the VM.

> There is lots of room for services in the documentation.
> There should be a "contributing services" section in chapter 8,
> currently I learn this the way I learned to do packages, by
> repetition and failure until I see how to debug stuff.. which is already 
> helping since I am starting to see patterns for debugging with darkhttpd (it 
> helped that it simply worked and then randomly broke in further attempts).
>
>
>
>
>

Re: how to create and test a new service definition

[Vincent Legoll]

On Sat, May 13, 2017 at 10:06 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Vincent Legoll <vincent.legoll@gmail.com> skribis:
>> ERROR: qemu failed "qemu-system-x86_64"
>
> What were the lines above this one?  This tool tries to use KVM if it
> seems available.  Maybe in your case it “seems” to be available (as in
> /dev/kvm exists) but is actually unusable?

Formatting '/gnu/store/miyri69r76ji72y6aq5xci8z2j68n5s1-qemu-image',
fmt=qcow2 size=31457280 encryption=off cluster_size=65536
lazy_refcounts=off refcount_bits=16
qemu-system-x86_64: error: failed to set MSR 0xd90 to 0x0
qemu-system-x86_64:
/tmp/guix-build-qemu-minimal-2.9.0.drv-0/qemu-2.9.0/target/i386/kvm.c:1833:
kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.
Backtrace:
In ice-9/boot-9.scm:
 160: 10 [catch #t #<catch-closure 8c5b80> ...]
In unknown file:
   ?: 9 [apply-smob/1 #<catch-closure 8c5b80>]
In ice-9/boot-9.scm:
  66: 8 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 7 [eval # #]
In ice-9/boot-9.scm:
2412: 6 [save-module-excursion #<procedure 8e67c0 at
ice-9/boot-9.scm:4084:3 ()>]
4089: 5 [#<procedure 8e67c0 at ice-9/boot-9.scm:4084:3 ()>]
1734: 4 [%start-stack load-stack #<procedure 8f69c0 at
ice-9/boot-9.scm:4080:10 ()>]
1739: 3 [#<procedure 8f86c0 ()>]
In unknown file:
   ?: 2 [primitive-load
"/gnu/store/rdpki7xkanivgb7jdczvk27kma47rj54-qemu-image-builder"]
In ./gnu/build/vm.scm:
 126: 1 [load-in-linux-vm
"/gnu/store/6mcs53r3ggy3csq7z4hwhx2iccfds3yn-linux-vm-loader" ...]
In unknown file:
   ?: 0 [scm-error misc-error #f "~A ~S" ("qemu failed"
"qemu-system-x86_64") #f]

ERROR: In procedure scm-error:
ERROR: qemu failed "qemu-system-x86_64"
environment variable `PATH' set to
`/gnu/store/rh3953267ifpb5bpl3l0f9vcmkx6zgl5-qemu-minimal-2.9.0/bin:/gnu/store/6908gy3pws0ccys49ni98idwnicchlr2-coreutils-8.26/bin'
builder for `/gnu/store/g2zyq34flqswxaikr0m774aizwbh0xdm-qemu-image.drv'
failed with exit code 1
cannot build derivation
`/gnu/store/qh5rvmv7rss59w4prb4bwq0r1m0jqwql-run-vm.sh.drv': 1
dependencies couldn't be built
guix system: error: build failed: build of
`/gnu/store/qh5rvmv7rss59w4prb4bwq0r1m0jqwql-run-vm.sh.drv' failed

Looks like kvm is there though, in my qemu guixsd VM:

vince@guixsd ~$ l /dev/*kvm*
crw-rw---- 1 root kvm 10, 232 May 14 10:36 /dev/kvm

Maybe use of qemu without hw assisted kvm would work when already in a
virtualized environment...

> ‘GUIX_PACKAGE_PATH’ is documented at
> <https://www.gnu.org/software/guix/manual/html_node/Package-Modules.html#index-GUIX_005fPACKAGE_005fPATH>.

Yes, that's where I finally found it again, with google's help, I
first searched there:

> <https://www.gnu.org/software/guix/manual/html_node/Defining-Packages.html>,
> <https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html>.

So I think adding something to these pages, maybe only linking to where it is
described would have been sufficient... WDYT ?

> There’s probably room for improvement though.  What changes/additions
> would you suggest?

I would suggest having a paragraph or 2 about how to setup a dev environment:
- using GUIX_PACKAGE_PATH
- setting up a link (where ?) to a local guix checkout

I read "8.1 Building from Git" and was frustrated by its avoidance to explain
how to do it. This is the logical (at least for me) place where this should be
explained.

I can try to add something about the env var, but cannot do the link thing, I
think this is what Catonano is speaking about :

> George suggested me the trick to link a checked out master branch to
> .local/guix/profile (or maybe it's the other way around: it's linking
> .local/guix/profile to a checked out master branch)

WDYT ?

>> guix edit is throwing me :
>> E166: Can't open linked file for writing
>
> This error does not come from ‘guix edit’, but maybe from your editor.
> As for why the file is read-only, see
> <https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-edit.html>.

And here is the other place where that variable is talked about, I
really fumbled
my research... So if something more substantial is put in 8.1, maybe we can just
link to it from there too...

Another idea, would be to enhance guix edit, like that:
if there's a user writable place for package definitions (either
GUIX_PACKAGE_PATH or a link to a local git checkout, or...), then guix edit
make a temp copy of the store file, if it is not modified, the copy is
thrown away
at guix edit exit and if it is modified, kept there...

WDYT ?

-- 
Vincent Legoll

Re: how to create and test a new service definition

[Catonano]

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

2017-05-14 10:44 GMT+02:00 Vincent Legoll <vincent.legoll@gmail.com>:

> On Sat, May 13, 2017 at 10:06 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> > Vincent Legoll <vincent.legoll@gmail.com> skribis:
> >> ERROR: qemu failed "qemu-system-x86_64"
> >
> > What were the lines above this one?  This tool tries to use KVM if it
> > seems available.  Maybe in your case it “seems” to be available (as in
> > /dev/kvm exists) but is actually unusable?
>
> Formatting '/gnu/store/miyri69r76ji72y6aq5xci8z2j68n5s1-qemu-image',
> fmt=qcow2 size=31457280 encryption=off cluster_size=65536
> lazy_refcounts=off refcount_bits=16
> qemu-system-x86_64: error: failed to set MSR 0xd90 to 0x0
> qemu-system-x86_64:
> /tmp/guix-build-qemu-minimal-2.9.0.drv-0/qemu-2.9.0/target/
> i386/kvm.c:1833:
> kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.
> Backtrace:
> In ice-9/boot-9.scm:
>  160: 10 [catch #t #<catch-closure 8c5b80> ...]
> In unknown file:
>    ?: 9 [apply-smob/1 #<catch-closure 8c5b80>]
> In ice-9/boot-9.scm:
>   66: 8 [call-with-prompt prompt0 ...]
> In ice-9/eval.scm:
>  432: 7 [eval # #]
> In ice-9/boot-9.scm:
> 2412: 6 [save-module-excursion #<procedure 8e67c0 at
> ice-9/boot-9.scm:4084:3 ()>]
> 4089: 5 [#<procedure 8e67c0 at ice-9/boot-9.scm:4084:3 ()>]
> 1734: 4 [%start-stack load-stack #<procedure 8f69c0 at
> ice-9/boot-9.scm:4080:10 ()>]
> 1739: 3 [#<procedure 8f86c0 ()>]
> In unknown file:
>    ?: 2 [primitive-load
> "/gnu/store/rdpki7xkanivgb7jdczvk27kma47rj54-qemu-image-builder"]
> In ./gnu/build/vm.scm:
>  126: 1 [load-in-linux-vm
> "/gnu/store/6mcs53r3ggy3csq7z4hwhx2iccfds3yn-linux-vm-loader" ...]
> In unknown file:
>    ?: 0 [scm-error misc-error #f "~A ~S" ("qemu failed"
> "qemu-system-x86_64") #f]
>
> ERROR: In procedure scm-error:
> ERROR: qemu failed "qemu-system-x86_64"
> environment variable `PATH' set to
> `/gnu/store/rh3953267ifpb5bpl3l0f9vcmkx6zgl5-qemu-minimal-2.9.0/bin:/
> gnu/store/6908gy3pws0ccys49ni98idwnicchlr2-coreutils-8.26/bin'
> builder for `/gnu/store/g2zyq34flqswxaikr0m774aizwbh0xdm-qemu-image.drv'
> failed with exit code 1
> cannot build derivation
> `/gnu/store/qh5rvmv7rss59w4prb4bwq0r1m0jqwql-run-vm.sh.drv': 1
> dependencies couldn't be built
> guix system: error: build failed: build of
> `/gnu/store/qh5rvmv7rss59w4prb4bwq0r1m0jqwql-run-vm.sh.drv' failed
>
> Looks like kvm is there though, in my qemu guixsd VM:
>
> vince@guixsd ~$ l /dev/*kvm*
> crw-rw---- 1 root kvm 10, 232 May 14 10:36 /dev/kvm
>
> Maybe use of qemu without hw assisted kvm would work when already in a
> virtualized environment...
>
> > ‘GUIX_PACKAGE_PATH’ is documented at
> > <https://www.gnu.org/software/guix/manual/html_node/Package-
> Modules.html#index-GUIX_005fPACKAGE_005fPATH>.
>
> Yes, that's where I finally found it again, with google's help, I
> first searched there:
>
> > <https://www.gnu.org/software/guix/manual/html_node/
> Defining-Packages.html>,
> > <https://www.gnu.org/software/guix/manual/html_node/
> Submitting-Patches.html>.
>
> So I think adding something to these pages, maybe only linking to where it
> is
> described would have been sufficient... WDYT ?
>
> > There’s probably room for improvement though.  What changes/additions
> > would you suggest?
>
> I would suggest having a paragraph or 2 about how to setup a dev
> environment:
> - using GUIX_PACKAGE_PATH
> - setting up a link (where ?) to a local guix checkout
>
> I read "8.1 Building from Git" and was frustrated by its avoidance to
> explain
> how to do it. This is the logical (at least for me) place where this
> should be
> explained.
>
> I can try to add something about the env var, but cannot do the link
> thing, I
> think this is what Catonano is speaking about :
>
> > George suggested me the trick to link a checked out master branch to
> > .local/guix/profile (or maybe it's the other way around: it's linking
> > .local/guix/profile to a checked out master branch)
>
> WDYT ?
>

Yes, I am referring to this
https://lists.gnu.org/archive/html/help-guix/2017-05/msg00090.html

[-- Attachment #2: Type: text/html, Size: 5697 bytes --]

Re: how to create and test a new service definition

[Ludovic Courtès]

Hi,

Vincent Legoll <vincent.legoll@gmail.com> skribis:

> On Sat, May 13, 2017 at 10:06 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> Vincent Legoll <vincent.legoll@gmail.com> skribis:
>>> ERROR: qemu failed "qemu-system-x86_64"
>>
>> What were the lines above this one?  This tool tries to use KVM if it
>> seems available.  Maybe in your case it “seems” to be available (as in
>> /dev/kvm exists) but is actually unusable?
>
> Formatting '/gnu/store/miyri69r76ji72y6aq5xci8z2j68n5s1-qemu-image',
> fmt=qcow2 size=31457280 encryption=off cluster_size=65536
> lazy_refcounts=off refcount_bits=16
> qemu-system-x86_64: error: failed to set MSR 0xd90 to 0x0
> qemu-system-x86_64:
> /tmp/guix-build-qemu-minimal-2.9.0.drv-0/qemu-2.9.0/target/i386/kvm.c:1833:
> kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.

A quick search gave me this:
<https://bugs.launchpad.net/qemu/+bug/1661386>.  It mentions a potential
VMware bug; are you using VMware for the “outer” VM?

>> ‘GUIX_PACKAGE_PATH’ is documented at
>> <https://www.gnu.org/software/guix/manual/html_node/Package-Modules.html#index-GUIX_005fPACKAGE_005fPATH>.
>
> Yes, that's where I finally found it again, with google's help, I
> first searched there:

I would recommend using the index in Info or one of:

  https://www.gnu.org/software/guix/manual/html_node/Concept-Index.html
  https://www.gnu.org/software/guix/manual/html_node/Programming-Index.html

>> <https://www.gnu.org/software/guix/manual/html_node/Defining-Packages.html>,
>> <https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html>.
>
> So I think adding something to these pages, maybe only linking to where it is
> described would have been sufficient... WDYT ?

OK, I’ve added a cross-ref from “Defining Packages” to “Package Modules”.

>> There’s probably room for improvement though.  What changes/additions
>> would you suggest?
>
> I would suggest having a paragraph or 2 about how to setup a dev environment:
> - using GUIX_PACKAGE_PATH
> - setting up a link (where ?) to a local guix checkout
>
> I read "8.1 Building from Git" and was frustrated by its avoidance to explain
> how to do it. This is the logical (at least for me) place where this should be
> explained.
>
> I can try to add something about the env var, but cannot do the link thing, I
> think this is what Catonano is speaking about :
>
>> George suggested me the trick to link a checked out master branch to
>> .local/guix/profile (or maybe it's the other way around: it's linking
>> .local/guix/profile to a checked out master branch)
>
> WDYT ?

I’m not sure what you’re suggesting.  Could you post a draft patch?  We
can work from there.

>>> guix edit is throwing me :
>>> E166: Can't open linked file for writing
>>
>> This error does not come from ‘guix edit’, but maybe from your editor.
>> As for why the file is read-only, see
>> <https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-edit.html>.
>
> And here is the other place where that variable is talked about, I
> really fumbled
> my research... So if something more substantial is put in 8.1, maybe we can just
> link to it from there too...
>
> Another idea, would be to enhance guix edit, like that:
> if there's a user writable place for package definitions (either
> GUIX_PACKAGE_PATH or a link to a local git checkout, or...), then guix edit
> make a temp copy of the store file, if it is not modified, the copy is
> thrown away
> at guix edit exit and if it is modified, kept there...
>
> WDYT ?

This is a great idea that’s been discussed before, and I would really
like to see it.  That said, it’s a “wishlist” item more than something
directly actionable.  Could you send this suggestion to bug-guix so we
can keep track of it?

Thanks,
Ludo’.