[Top][All Lists]

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

Re: A single reference to installed non-binaries

From: Edouard Klein
Subject: Re: A single reference to installed non-binaries
Date: Tue, 17 Aug 2021 16:01:15 +0200
User-agent: mu4e 1.4.15; emacs 27.2

Hi !

I side-step this kind of things by adding a stage in package-y that will
find and replace all references to "bar" with the complete path to the
installation path of package-x, or that will set the needed environment
variable to the full path of the dependency.

See e.g.

Here, xlsxio and tzdir will be expanded to their full install path in
the store.

It has the advantage of not needing to integrate any guix-realted stuff
in package-y, which I would consider an abstraction leak.

I hope this helps :)



Phil Beadling writes:

> Hi all,
> I have some platform independent files I have created a package for using
> copy-build-system.  This works great but I've come across situation I don't
> know how to handle.
> Let's call the package I've made package-x, and let's say that package-y
> (which is for arguments sake is a python build system) lists package-x as a
> propagated-input.
> package-x is installing a directory, let's say "bar" from the source into
> "share/foo/"
> '(#:install-plan '(("bar" "share/foo/")))
> Now whenever we install package-y, I should expect it's "share" directory
> to contain foo/bar - and I find it to be the case.
> No suprises so far.
> The problem comes when I want to reference a file under "bar" in the source
> code of package-y.
> Depending on whether I install package-y via "guix install package-y -p
> /path/to/profile" or via "guix environment --ad-hoc package-y" there is no
> single reference to the bar directory that covers every use-case.
> When I "install" the package - I can reference it using $GUIX_PROFILE
> But as for example a developer when I'm coding package-y I would reference
> This means that any source that references it must presumably attempt to
> read it from $GUIX_ENVIRONMENT, and then on failure fallback to
> This feels a bit brittle to me, and I'm hoping I've missed a trick, and
> there's a better way to singluarly reference the location of a share
> directory from any GUIX profile or environment?
> Note the problem doesn't happen with binaries as the order of precedence in
> the PATH variable avoids the issue.
> Any ideas?
> Thanks,
> Phil.

reply via email to

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