Re: [mh] collections.json being changed on $Pgm_Root?

Eloy Paris <[email protected]>
Newsgroups gmane.comp.misc.misterhouse.user
Message-ID <[email protected]>
I am not suggesting that the stock collections.json not be updated at
run time; I am suggesting that, just as we stop looking when we find
collections.json (for reading) outside of Pgm_Root, we do not update the
collections.json in the other locations after we find a viable
collections.json.

By doing it this way, if the user is using collections.json in one of
the locations outside of Pgm_Root then only that one would be updated,
and if the user chooses to use the stock collections.json then there
will be no collections.json elsewhere (otherwise they would be found
first) and the stock one would be updated.

Happy to propose a patch, if you are willing to consider it.

Related to this -- is there a reason for not keeping the stock
collections.json always at the latest version?

On Tue, Dec 11, 2018 at 09:16:54PM -0700, H Plato wrote:

> There was a case a while back where the collections wasn’t updated for someone, and it was because I didn’t update all the locations. If the stock isn’t updated, then it won’t work with the new versions of ia7 if anyone wanted to start fresh
> 
> Sent from my mobile device. 
> 
> > On Dec 11, 2018, at 8:55 PM, Eloy Paris <[email protected]> wrote:
> > 
> > Hi Howard,
> > 
> > If someone has configured data_dir or ia7_data_dir and collections.json
> > exists in one of those locations then why bother updating the stock file
> > -- it will never be used, updated or not, as we will first find the
> > collections.json in data_dir or ia7_data_dir and use that.
> > 
> > Cheers,
> > 
> > Eloy Paris.-
> > 
> >> On Tue, Dec 11, 2018 at 05:16:38PM -0700, H Plato wrote:
> >> 
> >> Reading & writing have this order of preference
> >> 
> >>        my $prefs_file = "$Pgm_Root/data/web/ia7_config.json";
> >>        $prefs_file = "$config_parms{data_dir}/web/ia7_config.json"
> >>          if -e "$config_parms{data_dir}/web/ia7_config.json";
> >>        $prefs_file = "$config_parms{ia7_data_dir}/ia7_config.json"
> >>          if -e "$config_parms{ia7_data_dir}/ia7_config.json”;
> >> 
> >> 1st priority is if someone actually set a specific config.ini ia7_data_dir, then if there is a custom data_dir, lastly use the stock file. 
> >> 
> >> The upgrader adds specific functionality to all the file locations. Some versions of IA7 need certain collection.json items, so I thought it would be safest to ensure that any files in those locations are up to date.
> >> 
> >> Am I missing something?
> >> 
> >>> On Dec 11, 2018, at 2:36 PM, Eloy Paris <[email protected]> wrote:
> >>> 
> >>> Hi Howard,
> >>> 
> >>> Question on collections.json...
> >>> 
> >>> I set data_dir in my .ini file to avoid writing to $Pgm_Root/data. That
> >>> way git never finds a modified file in $Pgm_Root/data and I keep the
> >>> source code tree separate from the data (I'm guessing this is how
> >>> everybody does it).
> >>> 
> >>> I just found out that ia7_update_collection() in lib/ia7_utilities.pl
> >>> will update all collections.json files in all locations
> >>> ($Pgm_Root/data/web/, $config_parms{data_dir}/web/, and
> >>> $config_parms{ia7_data_dir}/).
> >>> 
> >>> However, when reading the file, we seem to use the order
> >>> $config_parms{data_dir}/web/, $config_parms{ia7_data_dir}/, and
> >>> $Pgm_Root/data/web/, and stop with the first one we find.
> >>> 
> >>> (And similar for writing in json_write_file() -- we write to the first
> >>> we find and then stop.)
> >>> 
> >>> Is there any reason for updating the same file in all locations,
> >>> especially the one at $Pgm_Root/data/web/ (which will throw git off);
> >>> should we just no update the first one we find?
> >>> 
> >>> Cheers,
> >>> 
> >>> Eloy Paris.-
> >>> 


________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.