RE: units issues

["Buchbinder, Barry (NIH/NIAID) [E]" <BBuchbinder at niaid dot nih dot gov>]

Brian Inglis sent the following at Tuesday, May 23, 2017 10:37 PM
>
>On 2017-05-23 17:55, Doug Henderson wrote:
>
>> On 23 May 2017 at 15:49, Brian Inglis wrote:
>>
>>> Updating the currencies only when setup is run seems to me to be
>>> insufficient if users want to use current currency conversions.
>>
>> Currencies needs to be split to a different package from non-currency
>> units. Non-currency units is very static, whereas most currencies
>> changes daily. In the absence of updates, non-currency units are still
>> useful; but currencies are incorrect in most cases, and increasingly
>> so as time pass.
>>
>> It is difficult to predict user requirements based on current package
>> dependencies as non-currency units and currencies are likely used by
>> almost disjoint sets of packages. Users of non-currency units should
>> not be burdened by the complexities of currencies. But if they do need
>> currencies, they should be up to date.
>>
>> A possible solution is to check the currency of the currency data on
>> library initialization or each use by comparing the current date with
>> the data's date of update. When the data is stale, automatically
>> update it if possible, or notify the user of the problem.
>
>It's a command line utility from GNU with currency conversion factors
>in a separate definition file included from the main file, updated by
>a Python script, which downloads an RSS XML file of current (Euro)
>rates from a free source with a permissive licence, and converts it to
>definitions acceptable to the utility, overwriting the existing file.
>
>The main issues are that, as currently implemented, currency rates are
>updated automatically by a postinstall script only when setup is run;
>setup may be running in an environment without external access, so the
>postinstall script will generate an error; users may not want or care
>about currency updates; and the postinstall script uses find to avoid
>updating if there is no currency file, or it has been updated recently.
>
>One option to deal with this is update the package to install a
>zero length currency definitions file, so currency conversions are
>not defined, but the program has no issues, and drop the permanent
>postinstall script to perform updates. Then announce and document that
>users who want updated currency conversion rates need to run the update
>script from the command line, a profile script, cron job, or Windows
>Scheduled Task, as is desirable if they use currency conversions.
>
>There are also issues with the Python update script, as the currency
>source site cert expired recently, causing the update and postinstall
>scripts to fail, with no workaround other than a replacement or patch;
>and a poster has problems using the update script with Windows proxies,
>which I have addressed to the upstream maintainer for discussion about
>approaches. If there is no response, I will create a Cygwin update patch
>and submit it upstream, but there has been no visible response to issues
>raised on the GNU site.

I would prefer that by default updates happen automatically and those
who do not want automatic updates do something to stop them from
happening.  For instance, someone who does not want updates makes the
definitions file read-only and have the script check for write
permission and exit or skip updating if the file cannot be written.  A
zero length read-only file works if one is worried about someone using
stale conversion factors.  An environmental variable whose existence
marks no-update might be another possibility.

Best wishes,

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.