[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A single reference to installed non-binaries

From: Phil
Subject: Re: A single reference to installed non-binaries
Date: Tue, 17 Aug 2021 16:45:57 +0100
User-agent: mu4e 1.4.15; emacs 27.2

Thanks for comments Edouard!  Responses inline.

Edouard Klein writes:

> See e.g.

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]