Error in CI:

==> Error: Version requirement 2.7.2 on uwtools for uwtools cannot match any known version from package.py or externals

Error in CI:

==> Error: Version requirement 2.7.2 on uwtools for uwtools cannot match any known version from package.py or externals

uwtools/package.py

version("2.7.2", sha256="56816d543664792258bfa7dfb7e4cc66f794959dc92dc3710021f40a2b8571a4")

spack-stack@develop isn't using spack@spack-stack-dev ?

spack-stack/.gitmodules

[submodule "spack"]
  path = spack
  url = https://github.com/jcsda/spack
  branch = spack-stack-dev

Apparently not, somewhat to my surprise, but rather spack @ 43381fe, and unfortunately Update uwtools #557 won't be merged because of the delay in having it reviewed ~3 weeks ago.

I'll change v2.7.2 to v2.7.1 for now, and it will all go away when the move to spack-packages is made.

We can also merge the 2.7.2 PR if it's needed, since there is a corresponding PR in the new spack-packages repo. I didn't know this was urgent.

I am confused, is this just a matter of forwarding the spack submodule ptr? You can easily do this here.

We can also merge the 2.7.2 PR if it's needed, since there is a corresponding PR in the new spack-packages repo. I didn't know this was urgent.

It's not urgent; it does allow the folks who are relying on global-workflow-env to integrate uwtools instead of having it outside the environment they're using. As they've been getting along to date without this change, it can wait.

CI/CD failures are fixed by the change to orion's common/packages.yaml, so not directly related.

CI/CD does test spack-stack@develop and when that's cloned:

Submodule path 'spack': checked out '43381fe761f7280ac91fbdda462f86a062979843'

This is a chicken-and-egg problem, and as I agree with your previous statement about not merging Update uwtools #557.

If you're OK with the following:

change this PR to remove the uwtools changes, and simply fix openssl / py-cryptography so as to fix CI/CD and have a positive future basis for when automation work becomes prioritized again

that's what I'll do.

Let's just merge the spack PR and the equivalent spack-packages PR now; then you can update the submodule pointer for spack here and we are all set?

@rickgrubin-noaa New hash for spack is 29265cf

@rickgrubin-noaa New hash for spack is 29265cf

Thanks; that's concretized and building.

Have to leave [email protected] -- trying v2.8.2 triggers the dependency for [email protected]:, which in turn requires py-python-dateutil/package.py to need

version(
        "2.9.0.post0", sha256="37dd54208da7e1cd875388217d5e00ebd4179249f90fb72437e91a35459a0ad3"
    )

That's already in the spack-packages repo recipe, so should be ready for [email protected]

@rickgrubin-noaa New hash for spack is 29265cf

spack-stack@uwtools-gw-ue with spack@29265cf successfully builds on orion -- merging here ought to fix CI, yes?

$ git branch
  develop
  release/1.9.0
* uwtools-gw-ue

$ git submodule status
 607d9b4633395b4be88d87a1df88b46302d48d0c doc/CMakeModules (v1.0.0-32-g607d9b4)
 29265cff4abb9a7f48e19165ee0bdaf6ceb8d317 spack (spack-stack-1.9.1-1650-g29265cff4a)

Please update the spack submodule pointer to JCSDA/spack@e5820ed and pull in develop here. Thanks!

Please update the spack submodule pointer to JCSDA/spack@e5820ed and pull in develop here. Thanks!

Done.