Create Spack package for GridKit

[pelesh]

Create a Spack package and make a pull request to Spack upstream. Manage SUNDIALS and Ipopt dependencies with their dependencies such as KLU, METIS, BLAS/LAPACK, etc.

This issue includes following actions:

• [ ] Build GridKit without Spack
• [ ] Build GridKit dependencies with Spack, but GridKit without Spack
• [ ] Develop package.py for GridKit and build this locally (using spack develop as this will also be used in CI)

[stonecoldhughes]

@pelesh How about this as a proposed process:

1. clone and build GridKit locally with local sundials installation
2. clone and build GridKit locally with Spack sundials installation
3. setup a CI pipeline to acquire the Spack Sundials package and use the spack build cache action to cache it. Enable this pipeline with a manual trigger, verify it is caching the sundials package.
4. Add a step to clone GridKit in this CI pipeline
5. Add a step to build GridKit in the pipeline. Reference step 2 for details
6. Add a step to run GridKit tests in the pipeline
7. Begin the process of creating a spack package out of the GridKit source - create a package.py file

[pelesh]

This issue is about creating Spack package for GridKit only. I would use Re::Solve Spack package as a template. For now, GridKit dependencies are SUNDIALS and Ipopt. Once we have a working Spack package with vanilla configuration of SUNDIALS and Ipopt, we can improve it by requesting specific configuration for each dependency.

@cameronrutherford, feel free to chime in.

[cameronrutherford]

@pelesh How about this as a proposed process:

1. clone and build GridKit locally with local sundials installation
2. clone and build GridKit locally with Spack sundials installation
3. setup a CI pipeline to acquire the Spack Sundials package and use the spack build cache action to cache it. Enable this pipeline with a manual trigger, verify it is caching the sundials package.
4. Add a step to clone GridKit in this CI pipeline
5. Add a step to build GridKit in the pipeline. Reference step 2 for details
6. Add a step to run GridKit tests in the pipeline
7. Begin the process of creating a spack package out of the GridKit source - create a package.py file

I think this is a good rough outline, but I would perhaps reduce the steps here (this is the approach that I would take if doing the task myself):

1. Build GridKit without Spack
2. Build GridKit dependencies with Spack, but GridKit without Spack
3. Develop package.py for GridKit and build this locally (using spack develop as this will also be used in CI)
4. Have CI pipeline build GridKit using spack
5. Use spack develop in pipeline to build with custom source files
6. Add test invocations to pipelines

It's a slight re-ordering. Admittedly steps 3,4,5 and 6 from your outline could be inserted between my steps 2 and 3. This would give you a better understand of GitHub actions if you would like that learning opportunity. IMO this over-complicates things, and will be re-written for your end result in the end, so I suggest taking my ordering as the easiest way to do this, but perhaps not the most conducive to learning.

[cameronrutherford]

Note as well that you'll have to either use a custom spack fork in your pipelines, or add a custom spack repo https://spack.readthedocs.io/en/latest/repositories.html to use your WIP package.py that isn't merged into spack main

[pelesh]

I suggest doing steps 1-3 as outlined by @cameronrutherford. The rest will be tracked in other issues.

I think first good step would be to build GridKit with all dependencies using Spack locally.

[stonecoldhughes]

@cameronrutherford I agree with these suggested steps; as you said, a spack package then CI pipeline (2 steps) is less work than half-spacked CI pipeline, then spack package, then overwrite the pipeline (3 steps). @pelesh I can narrow the scope of the draft PR to just treat those steps 1-3; a more minimal set of incremental set of changes like that is always preferable.