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

[hagar]

On 23/1/19 12:11 am, Bert Peters via aur-general wrote:
> 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.

If the Environment variable is actually the  problem, why not just unset 
them before proceeding?


unset GEM_HOME

unset BUNDLE_PATH

`$(gem env gemdir)`


Thanks Macca