[petsc-dev] [Mike McQuaid] Re: [Homebrew/homebrew-core] PETSc: import from homebrew-science (#23598)

[Satish Balay]

$ ls |cat
adiforfix.py*
configVars.py*
FASTMathInstaller.py*
maint/
parseargs.py*
PetscBinaryIO.py*
PetscBinaryIO_tests.py*
PetscBinaryIOTrajectory.py*
petsc_conf.py*
petscdiff*
petsc_gen_xdmf.py*
petsclogformat.py*
petscmpiexec*
petsc-mpiexec.uni*
petscnagupgrade.py*
petscnagupgrade.pyc
petscrun*
popup*
portabilitycheck.py*
saws/
sendToJenkins*
taucc.py*
TOPSGenerator.py*
uncrustify.cfg
update.py*
win32fe/



I guess most of them are not needed - and whats needed can perhaps be somehow trimmed.

The new testsuite tries to use 'petscdiff' above.

And old makefiles try to use 'petscnagupgrade.py' - which is not appropriate for distributions anyway [but requires a patch to disable]

Satish

On Fri, 23 Feb 2018, Smith, Barry F. wrote:

> 
>   Jed,
> 
>     I am getting into this thread a little late. What is, exactly, what we need to change with ./configure ; make ; make install to make the PETSc "upstream installation" not a mess?  Are we simply over installing stuff? (This could be). Is it the optional dependency handling? 
> 
>    In bin we have 
> 
> 	petsc_gen_xdmf.py, 	PetscBinaryIO.py 	PetscBinaryIOTrajectory.py that probably belong elsewhere. 
> 
>    You should feel free to make branches that move this kind of stuff to more appropriate places and stop installing unneeded crap, but you can't expect someone else on the PETSc team to magically fix misinstalls and you need to be proactive as well.
> 
>    Barry
> 
>    It is important to follow "standards" when possible even if they are a bit annoying so long as they don't totally ruin the user experience. Our current install is not written in stone and can be adjusted to make package people happy if possible.
> 
> 
> 
> 
> 
> > On Feb 23, 2018, at 2:19 PM, Jed Brown <jed at jedbrown.org> wrote:
> > 
> > What, if anything, really needs to be installed to $prefix/bin?
> > 
> > From the Homebrew lead maintainer.
> > 
> > 
> > From: Mike McQuaid <notifications at github.com>
> > Subject: Re: [Homebrew/homebrew-core] PETSc: import from homebrew-science (#23598)
> > Date: February 23, 2018 at 1:59:53 PM CST
> > To: Homebrew/homebrew-core <homebrew-core at noreply.github.com>
> > Cc: Jed Brown <jed at jedbrown.org>, Mention <mention at noreply.github.com>
> > Reply-To: Homebrew/homebrew-core <reply+00000ce7ce699f5d2e67cfb5b15ac92562f1255ca51ef0f992cf0000000116a834b992a169ce11832314 at reply.github.com>
> > 
> > 
> > doesn't this attitude complete defeat the purpose of a package manager?
> > 
> > You're asking of the hardest working package manager maintainers in the world (@ilovezfs). Chances he has a better idea about the purpose of a package manager than you do.
> > 
> > I cannot understand not wanting a package because it is complicated to install.
> > 
> > This is perhaps because you do not maintain a package manager.
> > 
> > What you're suggesting is that any software using PETSc should either force users to compile it from scratch or discontinue supporting macOS entirely.
> > 
> > No, what's being suggested is that PETSc's currently upstream installation is a mess and we don't want to maintain the hacks required to make it not one indefinitely. You can copy and paste this formula as-is into a tap and it'll work for you just fine.
> > 
> > That seems like the wrong approach for a package manager.
> > 
> > In the package manager you maintain you should take a different approach, then.
> > 
> > Just my opinion...
> > 
> > If you have to end your statement like that: it's probably worth keeping quiet in future, please.
> > 
> > To be clear, I'm not being harsh here because I like doing so but because this entitled, know-it-all attitude literally kills open source projects and @ilovezfs's motivation is more important to me than allowing that to go unchallenged.
> > 
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub, or mute the thread.
> > 
> > 
> > 
> 
>