all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: 宋文武 <iyzsong@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Guix-devel <Guix-devel@gnu.org>
Subject: Re: Search paths vs. environment variables that designate a single file
Date: Thu, 21 May 2015 23:05:07 +0800	[thread overview]
Message-ID: <877fs26kf0.fsf@gmail.com> (raw)
In-Reply-To: <87lhgi73ma.fsf_-_@gnu.org>

Ludovic Courtès <ludo@gnu.org> writes:

> 宋文武 <iyzsong@gmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> With commit dbc31ab, it is now possible to do things like:
>>>
>>>   eval `guix package --search-paths=suffix`
>>>
>>> to augment the search path environment variables instead of overriding
>>> them.
>> Doesn't the KIND field belong to 'search-path-specification'?
>> Some variables are exact (GDK_PIXBUF_MODULE_FILE, GTK_DATA_PREFIX, etc.)
>> by definition.
>
> What do you mean?
>
> Here ‘exact’ means:
>
>   export PATH=/foo
>
> whereas ‘prefix’ means:
>
>   export PATH=/foo:$PATH
>
> This is not a property of the ‘PATH’ variable, but rather a choice that
> the user can make.
OK.
>
> What makes ‘GDK_PIXBUF_MODULE_FILE’ particular?  From the name I’m
> guessing it is *not* a search path, but rather is meant to specify a
> single file.  This is not what ‘search-path-specification’ is for, at
> least in its current form.
Yes, that's right.
>
>> I'd like to add 'GTK_DATA_PREFIX' and 'GTK_EXE_PREFIX' to gtk+
>> as 'exact' native-search-paths.
>> They generate value to profile as:
>>   - /run/current-system/profile, if you have installed xfce system wide.
>>   - ~/.guix-profile, if you installed xfce into user's profile.
>> So, the GTK+ themes will work out-of-box.
>
> Likewise, it seems that these are not search paths.
>
> This is not the first time there’s this temptation to use
> ‘search-path-specification’ for things that are not search paths.
> Clearly there seems to be a need for a similar mechanism, but we need to
> find a way for formalize it.
Hm, currently the 'search-paths' is the only way for a specified package
to populate environment variables into profile (and builder).  I tend to
think 'search-paths' are designed for build, but they are unually useful
(and same) for profile too.
>
> One way might be to augment ‘search-path-specification’ to support
> “single-item search paths” that basically designate a single file.
>
Yes, but some conflicted inputs will bring headahce to builder.
For 'GDK_PIXBUF_MODULE_FILE', both gdk-pixbuf and librsvg have
loaders.cache file, how we ensure the one from librsvg is selected?

> Or we could come up with a different mechanism, but it’s not clear to me
> what that would be.
I have no idea about now too.

Thanks!

  reply	other threads:[~2015-05-21 15:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-20 10:16 guix package --search-paths Ludovic Courtès
2015-05-20 15:15 ` 宋文武
2015-05-21  8:10   ` Search paths vs. environment variables that designate a single file Ludovic Courtès
2015-05-21 15:05     ` 宋文武 [this message]
2015-05-21 20:04       ` Ludovic Courtès

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

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

  git send-email \
    --in-reply-to=877fs26kf0.fsf@gmail.com \
    --to=iyzsong@gmail.com \
    --cc=Guix-devel@gnu.org \
    --cc=ludo@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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.