Re: A single reference to installed non-binaries

[Phil <phil@beadling.co.uk>]

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?

> 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.

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.

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.