Re: [mh] CPAN modules in MH

No one seems to be object to moving those CPAN modules to a 
lower-priority directory (below the system directories), so I submitted 
that pull request.

I now see that the Travis CI test failed.  Apparently there are some 
test routines that also manually build @INC, and they need to be updated 
too..  Here's the relevant part of the log:

06/05/19 05:21:29 AM Starting the test routines...
Process start: cmd_path=./get_url cmd=./get_url -post 'testparameter=1' 
http://httpbin.org/post /tmp/get_url_post.txt
Process start: parent pid=3916 type=external cmd=./get_url -post 
'testparameter=1' http://httpbin.org/post /tmp/get_url_post.txt
Process start: child type=external cmd=./get_url -post 'testparameter=1' 
http://httpbin.org/post /tmp/get_url_post.txt
Can't locate LWP/UserAgent.pm in @INC (you may need to install the 
LWP::UserAgent module) (@INC contains: ./../lib ./../lib/site /etc/perl 
/usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 
/usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 
/usr/local/lib/site_perl .) at ./get_url line 103.

LWP::UserAgent was moved to the new lib/fallback directory, but 
"lib/fallback isn't listed in @INC for the test routines.  I can't find 
where this test code is.  Does anyone have ideas where I should look for it?

            -Brian M.

On 5/30/19 8:15 PM, H Plato wrote:
> That makes sense to me. I think modernizing some of those modules is a 
> good idea with all the new functionality in v5+. I’d be willing to 
> test out your idea on my setup.
>
>> On May 30, 2019, at 7:51 PM, Brian M <[email protected] 
>> <mailto:[email protected]>> wrote:
>>
>> I have a change I'd like to submit to the MH development team, but it 
>> might have implications I'm not aware of or be controversial.  I 
>> thought I'd start a discussion here first, so I could get the input 
>> of the development team and others before simply submitting a pull 
>> request.
>>
>> MisterHouse comes with some CPAN modules prepackaged into it.  The 
>> reasons for this have been discussed before, and I don't really want 
>> to reopen that topic here.  We can open a separate thread for that if 
>> we want to reconsider that decision.  Sufficient for now to say that 
>> there are CPAN modules embedded in the code tree, and that in some 
>> cases they're quite behind the current versions available via CPAN or 
>> what the O/S distros offer.
>>
>> The problem is that as MisterHouse is currently structured, the 
>> system administrator or system owner is unable to cleanly updating 
>> the CPAN modules with newer versions, assuming the individual even 
>> knows they're there.  The modules live in the lib/site directory 
>> tree, and on start-up MisterHouse inserts that and other directories 
>> at the front of @INC, so that any system-supplied versions are 
>> ignored.  MisterHouse is saying in effect if not intent: "I know 
>> better than you do what versions you should run."  The individual can 
>> certainly go into the folder and replace the modules by hand, but at 
>> this point they're modifying the distributed code, creating a 
>> permanent maintenance hassle for themselves whenever they update 
>> MisterHouse.
>>
>> In my case, I spent many hours trying to figure out why my code to 
>> talk to my new thermostat would work outside of MisterHouse, but not 
>> inside it.  I eventually discovered that MH has a copy of 
>> LWP::UserAgent that is too old to support SSL connections.
>>
>> My proposed solution is pretty simple:
>>
>>  1. We create a new directory under lib, as a peer to lib/site.  I'm
>>     open to suggestions for the names, but for now I'll call it
>>     lib/fallback.
>>  2. We move the MH-supplied versions of the CPAN modules into
>>     lib/fallback.
>>  3. We add one line of code to the mh main program that adds
>>     lib/fallback to the *end* of @INC.
>>
>> The result would be that if the system owner/administrator provided a 
>> version of a module elsewhere in the normal PERL search path, MH 
>> would use it.  If no such module exists, MH will use the version in 
>> fallback.  That way, MH would be assured to find a copy of the 
>> module, and if the local administrator wanted a newer version they 
>> could install one without changing MisterHouse's distributed code.
>>
>> I've tried it on my own installation and it seems to be working 
>> well.  I'd be willing to code up the change and submit it, if the 
>> community doesn't have any objections.
>>
>> I look forward to people's thoughts about this.
>>
>>  -Brian M
>> ________________________________________________________
>> To unsubscribe from this list, go to: 
>> https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>>
>

________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users