[petsc-dev] --download and spack

[Jed Brown]

"Balay, Satish" <balay at mcs.anl.gov> writes:

> On Sun, 21 Oct 2018, Jed Brown wrote:
>
>> "Balay, Satish" <balay at mcs.anl.gov> writes:
>> 
>> > On Sun, 21 Oct 2018, Jed Brown wrote:
>> >
>> >> "Balay, Satish" <balay at mcs.anl.gov> writes:
>> >> 
>> >> > I don't think spack is really a replacemet for --download-package yet.
>> >> >
>> >> > For one - it has some initial setup hump users have to go over. [how
>> >> > does one specify compilers, and my prebuilt MPI?]
>> >> 
>> >> The configuration profile is somewhat clumsy, but lots of facilities do
>> >> it.  If PETSc were to support using spack for prerequisites, we would
>> >> probably want PETSc to be able to set it up.
>> >> 
>> >> > And then - we would need to update petsc support in spack to be as
>> >> > externsive wrt externalpackages as we currently have.
>> >> 
>> >> There are separate ideas:
>> >> 
>> >> * ./configure --download-hypre=spack
>> >> 
>> >>   or some similar syntax tells configure to ask Spack how to link to a
>> >>   suitably-built Hypre and to install it if necessary, resolving any
>> >>   possible transitive dependencies [1].
>> >
>> > I don't think spack is designed to support this model [just install
>> > one package or a subset of pacakges - per our spec]. For one - it
>> > doesn't have a configure like interface to pass options from petsc
>> > configure to spack [for all the checks that petsc configure has
>> > already done.
>> >
>> >> 
>> >> * spack install petsc+hypre
>> >> 
>> >>   as a recommended way for users to install.  An issue with this is that
>> >>   Spack code runs before anything PETSc works with, and Spack setup
>> >>   (system compilers, MPI, etc.) can be nontrivial.
>> >
>> > This is the recommended mode. And I think its useful for users who don't
>> > want to deal with petsc directly or petsc interface directly.
>> >
>> > [for ex: deal.ii users - who want to install deal.ii - but just want a
>> > compatible petsc installed automatically].
>> 
>> This is *exactly* the same model as you rejected a paragraph above.
>> There is no difference whether we are talking about installing
>> dependencies for PETSc or dependencies for Deal.II.
>
> Not really. My initial claim was 'spack was not yet a replacement for
> --download-package' option in PETSc. I don't think deal has this
> feature.

Okay, fair enough.  But if it's usable for installing dependencies
needed by a typical deal.II user, it should also be usable for
installing PETSc's dependencies.

>> Also, I think most users don't care whether exactly the same compiler
>> options are passed to all dependent packages.  They want to link against
>> a working debug or optimized stack with minimal build time.
>> 
>> >> [1] Having configure churn for a while and then say that --download-zlib
>> >> or --enable-zlib is required is super lame.
>> >
>> > spack automatically figures out and installs tonnes of additional packages. The
>> > above model gives the choice of user deciding what to do. In case of p4est - it could
>> > be an optionl dependency instead of mandatory dependency.
>> >
>> > I guess optional dependency handling is a bit complex.
>> 
>> It is, but if we're downloading a bunch of packages and zlib is deemed
>> required, we shouldn't fail.  It's these minutes of babysitting
>> configure and needing to start over to add non-obvious dependencies that
>> is infuriating and drives people away from PETSc and/or blocks them from
>> running their code at new facilities.  (It's a completely different
>> calculus if I know I can log in, issue a couple simple commands, and be
>> running in 5-10 minutes versus if I expect to need to babysit and
>> troubleshoot configuration idiosyncrasies for hours.)
>
> In my case - I have spack running for 4-6h - and then I get an error -
> and then I have to figureout how to work arround them - and restart
> builds. Different tools have different error cases..

I agree it can be irritating, though Spack is reasonably reliable about
caching previous builds so it usually isn't starting over from scratch
after fixing any particular issue.

And I didn't mean that the zlib thing on its own is a reason to use
Spack, but that PETSc configure should either return immediately (<5
seconds) if the dependency graph is incomplete and/or try to do what the
user surely wants and find a zlib.