[GNC] gnucash-cli says, "No quotes retrieved. Finance::Quote isn't installed properly" on macOS

[John Ralls]

> On Jun 12, 2021, at 11:49 PM, Jim DeLaHunt <list+gnucash at jdlh.com> wrote:
> 
> On 2021-06-12 20:49, John Ralls wrote:
>> 
>>> On Jun 12, 2021, at 6:31 PM, Jim DeLaHunt <list+gnucash at jdlh.com> wrote:
>>> 
>>> On 2021-06-12 09:13, John Ralls wrote:
>>> 
>>>>> On Jun 12, 2021, at 12:22 AM, Jim DeLaHunt <list+gnucash at jdlh.com> wrote:
>>>>> 
>>>>> OK, I can understand that the MacPorts installation of perl may be configured to look for perl packages in MacPorts locations, and ignore the system locations. But I don't understand wny the GUI app of GnuCash apparently can find Finance::Quote when run from the GUI, but the gnucash-cli app apparently cannot. What is different?
>>>> Because applications started by LaunchServices don't get the environment from your shell's startup files. That means GnuCash is running /usr/bin/perl, not /opt/local/bin/perl but when you run a program from Terminal the environment is read so gnucash-cli runs /opt/local/bin/perl.
>>> Thank you, John, this explanation is very helpful. I can understand that the GnuCash GUI and the gnucash-cli experience different environments, especially different $PATH values, because the OS invokes them in different environments.
>>> 
>>> But I find it very confusing to have gnucash-cli be presented as an integral part of GnuCash, and all the references to a singular action of "update Finance::Quote on the system", then have gnucash-cli behave differently and require a different installation of Finance::Quote than the GnuCash GUI.
>>> 
>>> It seems to me that if both gnucash-cli and the GnuCash GUI would invoke the perl executable at an absolute path, then they would have consistent behaviour. Thus I wonder why GnuCash lets the environment find the perl executable.
>>> 
>>> I have filed Bug 798209, "gnucash-cli might not use the same perl and Finance::Quote as GnuCash GUI", <https://bugs.gnucash.org/show_bug.cgi?id=798209> , to track this.
>>> 
>>> My workaround as a MacPorts user: install Finance::Quote into the MacPorts perl environment:
>>> 
>>> ```
>>> % port install p5-finance-quote
>> Jim,
>> 
>> I summarily dismissed your bug report. It's on users who modify their operating systems to know what they're doing.
>> 
>> It's standard practice nowadays to use the environment to get the executable to make it easy for users to set the one they want. That does require that users have a clue, but users without one who mess up their OS with package managers they don't understand have only themselves to blame.
> 
> As I said to David, I submit that installing packages with MacPorts or Homebrew has aspects of installing application software, as well as aspects of altering the OS. Installing application software is a reasonable thing for people to do with their personal computers. I don't think its reasonable to say that GnuCash should ignore the existence of MacPorts and Homebrew.
> 
> It would help for the gnucash-cli documentation to mention that GnuCash lets the environment pick which perl instance to run.
> 
> It would help for the Finance::Quote troubleshooting documentation to mention this problem, and the solution.
> 
> It would help for the GnuCash error message to also say, "Use `perl -e 'print join("\n", @INC), "\n";'` to see where perl is looking.".
> 
>> There's a really simple solution for you: Just install F::Q in both perls:
> Agreed, but…
>>   /opt/local/bin/perl /Applications/Gnucash.app/Contents/Resources/bin/gnc-fq-update
> 
> AFAIK it is bad practice to have anything but MacPorts install into the MacPorts directory tree. Maybe there are circumstances in which it works for perl modules in a MacPorts instance, but there are many stories of the MacPorts and other package managers conflicting. Fortunately, Finance::Quote is available via MacPorts. Thus I feel more confident with:
> 
> % sudo port install p5-finance-quote
> 
> I appreciate all the explanations. Thank you.

IMO installing MacPorts or Homebrew as those package managers intend changes the operating system. It's no longer macOS, it's MacPorts or Homebrew.

MacPorts correctly addresses the problem by supplying their own "port" for GnuCash. If you want to run MacPorts, use their GnuCash and if it doesn't work the way you expect, complain to them.

Homebrew, on the other hand, is different: They claim to have a recipe for GnuCash but all it does is download the dmg from Github.

There are several ways to work around the problem you've made for yourself; 
* Create a second user in System Preferences and not install the package manager's environment changes. Fast User Switching makes it easy to flip back and forth between the two.
* Remove the environment changes from your shell's rc files (e.g. .bash_profile and .bashrc if you use Bash as your shell) and put them in their own shell script that you'd source when you want package manager behavior or a shell script that removes the environment if you prefer to default to the package manager's environment.
* Always launch GnuCash from Terminal by specifying the path (don't use `open`, it calls LaunchServices and you'll get the clean environment) and override the shebang in gnc-fq-update by saying `perl gnc-fq-update`.
* Create a shell script to run gnucash-cli in a pure macOS environment.
* As I pointed out last night, install F::Q into both perls. 
* Edit /Applications/GnuCash.app/Contents/Resources/etc/gnucash/environment to include the line
   PATH=/bin:/usr/bin
  That's less than ideal because you'll have to redo the edit every time you install a new GnuCash.app.
* Build your own GnuCash from source, making whatever changes you like. That's the whole point of Free in Free Software.

Note that making a combined @INC isn't one of the options. A lot of perl modules have C components that need to link libperl. Trying to use one of those from a perl executable linked to a different libperl risks rather interesting behavior.

You asked Chris Good if any Linux package managers install multiple versions of perl. I don't know of any that do nor can I think of a reason why one would, but if one did it would use naming to differentiate them. There's nothing about Linux that stops a user from installing a custom perl somewhere, and that might create a similar problem if that user is careless about configuring their environment.

Regards,
John Ralls