Re: A single reference to installed non-binaries

[Edouard Klein <edou@rdklein.fr>]

Phil writes:

> Thanks for comments Edouard!  Responses inline.

:)

>
>
> Edouard Klein writes:
>
>
>> See e.g.
>> https://gitlab.com/edouardklein/guix/-/blob/beaverlabs/beaver/packages/scheme-xyz.scm#L68
>
> Ahh so wrap-program creates a script that sets the two env vars
> LD_LIBRARY_PATH and TZDIR before calling the original script?

Yes, it is exactly what it does, with the added cleverness that if the
original script is already a wrap, it edits the wrap instead of re-wrapping.
>
>> It has the advantage of not needing to integrate any guix-realted stuff
>> in package-y, which I would consider an abstraction leak.
>
> Yes it's nicer for the underlying program not to have to know about
> Guix.
>
> There is one small wrinkle with this in my particular case.  Whilst I
> can wrap the main entry point to the program easily enough, there is a
> second entry point via the unit tester (pytest), which is obviously an
> external tool so not so easy to wrap.
>
> I could patch the source code of the unit test itself as an alternative.
>

As you can see a bit below where I linked before, you can redefine the test
stage in order to set the correct environment variables before calling
your test command. It will be a bit redundant with the wrapping phase,
but it would allow you not to edit your application code.


> Another slightly more leftfield idea is to change (or add) package-x to be a
> python package which holds the original data files and a very thin API
> client that can serve those files up to Python.
>
> Then package-x's python module will be self-aware of its location, relative
> to the text files and we can serve up either a file path or file
> object to package-y just by importing package-x, and calling a function.
>

I don't know the particulars of your code, but package-x and package-y
seem to be quite coupled together, so I would question the assumption
that they belong in separate packages.

Maybe they do, nobody is better placed than you to judge. But putting
them both in the same package would make your problems disappear.


> The disadvantage of this would be if we had non-python clients
> too, but we could keep two different build systems for the same source -
> one copies the files, and the other installs a python module.
>
> I'll give this a whirl.


Good luck !

Cheers,

Edouard.