unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Phil <phil@beadling.co.uk>
To: Edouard Klein <edou@rdklein.fr>
Cc: help-guix@gnu.org
Subject: Re: A single reference to installed non-binaries
Date: Tue, 17 Aug 2021 16:45:57 +0100	[thread overview]
Message-ID: <87o89w9iru.fsf@beadling.co.uk> (raw)
In-Reply-To: <87v9442ms4.fsf@rdklein.fr>

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.


  reply	other threads:[~2021-08-17 15:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-17 11:31 A single reference to installed non-binaries Phil Beadling
2021-08-17 14:01 ` Edouard Klein
2021-08-17 15:45   ` Phil [this message]
2021-08-17 18:42     ` Edouard Klein
2021-08-17 20:42       ` Phil
2021-08-17 17:55   ` Leo Famulari
2021-08-17 18:49     ` Setting TZDIR (was Re: A single reference to installed non-binaries) Edouard Klein
2021-08-17 20:20       ` Leo Famulari

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o89w9iru.fsf@beadling.co.uk \
    --to=phil@beadling.co.uk \
    --cc=edou@rdklein.fr \
    --cc=help-guix@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).