"Smith, Barry F. via petsc-users" <petsc-users@mcs.anl.gov> writes:
> So it sounds like spack is still mostly a "package manager" where people > use "static" packages and don't hack the package's code. This is not > unreasonable, no other package manager supports hacking a package's code > easily, presumably. The problem is that in the HPC world a "packaged" > code is always incomplete and may need hacking or application of newly > generated patches and this is painful with static package managers so people > want to use the git repository directly and mange the build themselves which > negates the advantages of using a package manager. I don't think people "want" to hack the packages that they don't contribute to. Spack provides pretty rapid distribution of patches. What if PETSc had ./configure --with-mumps=spack or some alternative that would check with spack to find a suitable MUMPS, installing it (with Spack's dependency resolution) if not available? Then you could hack on PETSc with multiple PETSC_ARCH, branches, incremental rebuilds, and testing, but not need to deal with PETSc's crude package installation and upgrade mechanism. Upon completion, the build could offer a yaml snippet for packages.yaml in case the user wanted other Spack packages to use that PETSc.
