[petsc-dev] provider stuff in package.py

[Barry Smith]

  Originally each provider provided a single value which people could query later. 

  I had to modify the installProvider to provide multiple values; the —prefix install location and the $PETSC_DIR/$PETSC_ARCH location

   So why not just expose the providerObject as something that is used directly 

self.installDirProvider.installSudo
self.installDirProvider.dir
self.installDirProvider.confdir

  it can still be set package by package.     But you throw away all the messy getXXX() things that are there now and just use directly, for example
self.languageProvider.language self.precisionProvider.precision   etc etc?


Barry







On Sep 30, 2014, at 4:09 PM, Matthew Knepley <knepley at gmail.com> wrote:

> On Tue, Sep 30, 2014 at 4:00 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 
>   Matt,
> 
>     Can all the “provider” stuff in package.py like
> 
>   def getDefaultPrecision(self):
>     '''The precision of the library'''
>     if hasattr(self, 'precisionProvider'):
>       if hasattr(self.precisionProvider, 'precision'):
>         return self.precisionProvider.precision
>     return self._defaultPrecision
>   def setDefaultPrecision(self, defaultPrecision):
>     '''The precision of the library'''
>     self._defaultPrecision = defaultPrecision
>     return
>   defaultPrecision = property(getDefaultPrecision, setDefaultPrecision, doc = 'The precision of the library’)
> 
> be cleaned up/simplified/removed with the new BuildSystem model?
> 
> What was the original need for the provider stuff and is there still a need? If there is still a need can it be satisfied some other way. Is there every a need for a different provide for different packages? For example hypre gets one xxx provider and some other package gets a different xxxx provider.
> 
> The provider stuff is intended to support out-of-package ways to say something about the configuration. So we have an object
> that can come from anywhere. The stuff around it just access the object automatically, instead of making the user pull it out and
> reference it. I thought that was easier.
> 
> Do you want to just set a flag? I thought that was limiting, and duplicated information.
> 
> You can get rid of all this boilerplate code in newer version of Python. We have been
> outlawing newer versions. If we reopen that discussion, I vote for autoinstalling Python
> 2.7.
> 
>   Thanks,
> 
>     Matt
>  
>   Barry
> -- 
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> -- Norbert Wiener