Guix as a native-inputs ?

Guix as a native-inputs ?

[Olivier Dion via]

Hi,

I would like to use guix as a native-inputs for a package.  Is there any
issue with that?

-- 
Olivier Dion
oldiob.dev

Re: Guix as a native-inputs ?

[(]

On Mon Aug 1, 2022 at 7:45 PM BST, Olivier Dion via wrote:
> I would like to use guix as a native-inputs for a package.  Is there any
> issue with that?
Nope :)

    -- (

Re: Guix as a native-inputs ?

[Olivier Dion via]

On Mon, 01 Aug 2022, "(" <paren@disroot.org> wrote:
> On Mon Aug 1, 2022 at 7:45 PM BST, Olivier Dion via wrote:
>> I would like to use guix as a native-inputs for a package.  Is there any
>> issue with that?
> Nope :)

There seems to be an issue after all.  When building with Guix, my
script failed to access /var/guix/daemon-socket/socket with `guix
shell'.  I guess there's probably some way to make it available for the
build?

-- 
Olivier Dion
oldiob.dev

Re: Guix as a native-inputs ?

[(]

On Tue Aug 2, 2022 at 2:41 PM BST, Olivier Dion wrote:
> There seems to be an issue after all.  When building with Guix, my
> script failed to access /var/guix/daemon-socket/socket with `guix
> shell'.  I guess there's probably some way to make it available for the
> build?
You're in a container with access to nothing but the store and /tmp. It's
not surprising that trying to access anything else doesn't work.

Usually, `guix` is included as a regular input so that a Guile program can
use its modules (see gwl, guix-modules). I didn't realize that you were
trying to actually manipulate the store from within a build environment :)

    -- (

Re: Guix as a native-inputs ?

[Olivier Dion via]

On Tue, 02 Aug 2022, "(" <paren@disroot.org> wrote:
> On Tue Aug 2, 2022 at 2:41 PM BST, Olivier Dion wrote:
>> There seems to be an issue after all.  When building with Guix, my
>> script failed to access /var/guix/daemon-socket/socket with `guix
>> shell'.  I guess there's probably some way to make it available for the
>> build?
> You're in a container with access to nothing but the store and /tmp. It's
> not surprising that trying to access anything else doesn't work.

Right that was my though.  Do you thin there is a way to expose the
required files to the build container for accessing the Guix daemon?

I have at least another case -- a guix+guile declarative build system --
where I need to communicate with the Guix daemon in the build
container.

-- 
Olivier Dion
oldiob.dev

Re: Guix as a native-inputs ?

[Julien Lepiller]

If you're trying to access the build daemon from inside the package build container, that must mean you have a derivation you're trying to build. Instead of trying to circumvent the container (which is there for a reason), you could:

- write a bit of Scheme code that returns that derivation
- pass the result as an input.

That way, you build that derivation outside the build environment, and you can refer to the result inside the build environment.

Le 2 août 2022 17:36:19 GMT+02:00, Olivier Dion via <help-guix@gnu.org> a écrit :
>On Tue, 02 Aug 2022, "(" <paren@disroot.org> wrote:
>> On Tue Aug 2, 2022 at 2:41 PM BST, Olivier Dion wrote:
>>> There seems to be an issue after all.  When building with Guix, my
>>> script failed to access /var/guix/daemon-socket/socket with `guix
>>> shell'.  I guess there's probably some way to make it available for the
>>> build?
>> You're in a container with access to nothing but the store and /tmp. It's
>> not surprising that trying to access anything else doesn't work.
>
>Right that was my though.  Do you thin there is a way to expose the
>required files to the build container for accessing the Guix daemon?
>
>I have at least another case -- a guix+guile declarative build system --
>where I need to communicate with the Guix daemon in the build
>container.
>
>-- 
>Olivier Dion
>oldiob.dev
>

Re: Guix as a native-inputs ?

[Olivier Dion via]

On Tue, 02 Aug 2022, Julien Lepiller <julien@lepiller.eu> wrote:
> If you're trying to access the build daemon from inside the package
> build container, that must mean you have a derivation you're trying to
> build. Instead of trying to circumvent the container (which is there
> for a reason), you could:
>
> - write a bit of Scheme code that returns that derivation
> - pass the result as an input.
>
> That way, you build that derivation outside the build environment, and
> you can refer to the result inside the build environment.
>

Would that work if my package defines a Guix channel with variant of
Guix packages in it?  That is, it would be possible to include these
packages in as a derivation?

-- 
Olivier Dion
oldiob.dev

Re: Guix as a native-inputs ?

[Julien Lepiller]

I suppose once you get information about these channels, you could create an inferior with these channels, and evaluate your package in it.

Le 2 août 2022 19:10:31 GMT+02:00, Olivier Dion <olivier.dion@polymtl.ca> a écrit :
>On Tue, 02 Aug 2022, Julien Lepiller <julien@lepiller.eu> wrote:
>> If you're trying to access the build daemon from inside the package
>> build container, that must mean you have a derivation you're trying to
>> build. Instead of trying to circumvent the container (which is there
>> for a reason), you could:
>>
>> - write a bit of Scheme code that returns that derivation
>> - pass the result as an input.
>>
>> That way, you build that derivation outside the build environment, and
>> you can refer to the result inside the build environment.
>>
>
>Would that work if my package defines a Guix channel with variant of
>Guix packages in it?  That is, it would be possible to include these
>packages in as a derivation?
>
>-- 
>Olivier Dion
>oldiob.dev

Re: Guix as a native-inputs ?

[Olivier Dion via]

On Tue, 02 Aug 2022, Julien Lepiller <julien@lepiller.eu> wrote:
> I suppose once you get information about these channels, you could
> create an inferior with these channels, and evaluate your package in
> it.

I think I will have to go with your proposal.  I already have the
packages defined in my channel.  It's just a matter of making a list of
them and adding it to the native-inputs instead of using Guix.  However,
this mean that I have to copy these packages when adding my package
to Guix channel.  It's not too much of a hassle.

-- 
Olivier Dion
oldiob.dev

Re: Guix as a native-inputs ?

[(]

Although, what's your use-case for that anyway?

    -- (

Re: Guix as a native-inputs ?

[Tobias Geerinckx-Rice]

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

Hi Olivier,

Olivier Dion via 写道：
> I would like to use guix as a native-inputs for a package.

As ( implies, it's a strange thing to do.  There might be a better 
solution to whatever your unspecified problem is.

> Is there any issue with that?

Only that the ‘guix’ package in guix is older than the guix that 
contains it (the Guix which is building your package).  If you run 
‘(file-append #$guix "/bin/guix") shell FOO’ in the build 
environment, it might provide an older version of FOO than you'd 
get if you specified FOO as an input directly.

If you're using it in a test suite, that might not be a problem.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: Guix as a native-inputs ?

[Olivier Dion via]

On Mon, 01 Aug 2022, Tobias Geerinckx-Rice <me@tobias.gr> wrote:

> As ( implies, it's a strange thing to do.  There might be a better 
> solution to whatever your unspecified problem is.

Here's my full use case.

I do dynamic binary instrumentation.  I basicaly insert call/jump at
runtime in programs for executing callback.  I use Guix for its workflow
extension (GWL) to produce scientific metrics for my research.  I also
use Guix to run binaries in a profile with debug symbols available.  The
latter case is a stress test to see if the instrumenter keep the
integrity of the instrumented software.

For example I want to instrument `ls' from coreutils.  So I would need
`coreutils' and `coreutils:debug'.  These _could_ be added to the
native-inputs of my package.  However, I also want to test
instrumentation on many packages (~50).  These other packages lack the
`:debug' output that is required by my tools.  Furthermore, I don't want
to add a very long list of packages to my native-inputs and maintain it.

So what I do is that I have a Guix channel inside my project.  Inside
that channel I define all the packages that I need with the debug output
added.  I can then use them for testing like so
`guix shell -L .guix my-git my-git:debug'.

If you think there's a better solution then I'm open to heard it.

-- 
Olivier Dion
oldiob.dev