guix package --search-paths

guix package --search-paths

[Ludovic Courtès]

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.

Comments welcome!

Ludo’.

Re: guix package --search-paths

[宋文武]

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.

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.

Search paths vs. environment variables that designate a single file

[Ludovic Courtès]

宋文武 <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.

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.

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

One way might be to augment ‘search-path-specification’ to support
“single-item search paths” that basically designate a single file.

Or we could come up with a different mechanism, but it’s not clear to me
what that would be.

Thoughts?

Thanks,
Ludo’.

Re: Search paths vs. environment variables that designate a single file

[宋文武]

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!

Re: Search paths vs. environment variables that designate a single file

[Ludovic Courtès]

宋文武 <iyzsong@gmail.com> skribis:

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

[...]

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

I imagine the best we could do is to have a choose-first and a
choose-last policy, but I can’t imagine us adding a
for-GTK_PIXBUF_MODULE_FILE-make-sure-to-choose-librsvg-over-gdk-pixbuf.

So if that’s really the kind of policy that we want to express, we need
to find something else.

Ludo’.