Re: [mh] MisterHouse strategy for @INC and provided libs

[Lieven H. <li...@li...>]

Hey John,


Op 17-aug.-2013, om 14:07 heeft John <jo...@to...> het volgende geschreven:

> On 08/16/13 14:50, Lieven Hollevoet wrote:
> 
> [snip]
> 
>> Because I encountered this problem I started wondering: why are we not using CPAN to install required modules instead of providing our 'own' (old?) versions of default modules with the MisterHouse application? Keeping those up to date in our own archive seems bothersome to me and not really productive/useful?
>> 
>> Did we have experiences in the past that caused us to move away from CPAN? What is the reasoning behind this way of working?
> 
> The advantage would be that it would take more effort to test/update MH 
> core code as each of its dependent 3rd party modules changes (new 
> versions released).  This includes making sure the MH core works with 
> multiple versions of the same dependent module simultaneously.
> 
> The way it is currently we can set it and forget it.  We would only 
> utilize a new dependent module when MH requires something in that new 
> version.

That is one way of looking at it. On the other hand we're missing out all bug fixes that are applied to the modules we use too, because I don't believe somebody is monitoring the modules used by MisterHouse to see if it gets time to update the version that is delivered with the MisterHouse package. Could it not be we're building further on a codebase that was developed at a point in time when CPAN was not really stable enough to rely on? If this is the case then should we not go with the flow and make MisterHouse depend on recent version of modules and even offer MisterHouse through CPAN too?

'cpanm App::MisterHouse' would be a very nice way to install stable MisterHouse versions, isn't it?

> 
> As far as changing the default search path, I do not know where this is 
> being done.

It is in bin/mh in the setup_INC sub, but I don't see code there that explains the error message I'm getting.

> 
> As far as search order:  From your initial description it is not clear 
> when MH searches its own installation for 3rd party modules it requires. 

It is : @INC includes ./../lib ./../lib/site that are the MisterHouse module folders.

>   You mention "system path" and "default path" and it doesn't either of 
> those would be it own repository.

On OS X there is a system Perl installation that comes with the OS (5.12, I call this one the 'system Perl'). It is generally considered bad practice to install extra modules to the system Perl because of various reasons (conflicts on updates, errors in Perl modules that come with the installation…). When I install a 'custom' Perl with perlbrew then that Perl is the default Perl on the user account that runs MisterHouse.

So system Perl = 5.12, default Perl = 5.16 with the Mail::IMAPClient module installed.

If you look in the error report here https://github.com/hollie/misterhouse/issues/247 you see that @INC is an extended version of the search path of the system Perl and not of the expected default Perl of the user account while the other reports I give show that the default Perl is actually the one that is executed in the terminal where I launch MisterHouse from. 

I'll dig further into this but I was wondering if anybody else encountered this problem before.

Regards,
 Lieven.