[aur-general] TU application_R: Metal A-wing (a-wing)

[Bert Peters]

Levente Polyak via aur-general schreef op 2019-01-22 16:10:
> On January 22, 2019 4:03:29 PM GMT+01:00, Bert Peters via aur-general
> <aur-general at archlinux.org> wrote:
>> Levente Polyak via aur-general schreef op 2019-01-22 13:40:
>>> On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general
>>> <aur-general at archlinux.org> wrote:
>>>> David Runge schreef op 2019-01-22 12:30:
>>>>> On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote:
>>>>>> On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote:
>>>>>> Why is use
>>>>>> `$(gem env gemdir)`
>>>>>> 
>>>>>> Instead of
>>>>>> 
>>>>>> `$(ruby -e'puts Gem.default_dir')`
>>>>> It's shorter and you don't have to spawn a ruby process to print
>>>>> something, if you can use the gem command directly.
>>>> 
>>>> I'm not a TU so take my this with a grain of salt, but I don't think
>>>> this is the best advice.
>>>> 
>>>> It's shorter, admittedly, but `gem` spawns a ruby process just as
>> the
>>>> `ruby` version does. Using gem doesn't work however when `$GEM_HOME`
>> 
>>>> is
>>>> 
>>>> set, since then it reports the contents of that variable.
>>>> 
>>>> Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')`
>> 
>>>> is
>>>> 
>>>> more convenient since most users do not build in a clean chroot, and
>>>> the
>>>> wiki actually recommends settings that environment variable so quite
>> a
>>>> few will have it.
>>>> 
>>>> Best,
>>>> 
>>>> Bert Peters.
>>> 
>>> Which seems silly and the whole section should be removed in the
>> first
>>> place.
>>> Thats what --user-install switch should be for and that should be
>>> default via /etc/gemrc
>>> Therefor setting that is just useless fiddling with the system and
>>> your gems will be searched there as well as it's default gem path
>>> besides /usr/lib.
>> 
>> While `gem` obeys that default, `bundle` (ruby-bundler) does not, and
>> does not
>> have that default, opting for a global install by default. You can
>> override
>> this by manually adding `--path=~/.gem` to every invocation. That's
>> hardly an
>> elegant solution compared to setting an environment variable.
> 
> 
> Which is why "bundle config path" exists.
> A sane way would be to use that to define BUNDLE_PATH in 
> ~/.bundle/config

Fair enough, I did not know about that option. In that case the wiki 
(and my setup) needs some updating, since it explicitly recommends using 
GEM_HOME for this. I'll see if I can do something about that tonight.

That said, I'm not convinced there's any harm in using the longer 
method, since it's slightly more compatible (and technically faster! 
although not by enough to count it as a benefit). Looking through the 
community repo both are used.