Add py-fortranformat to neptune-env

[eap]

Add the package py-fortranformat to neptune-env. Note that neptune-env as loaded by the unified environment template is the ~python variant so this package had to be modified manually.

Testing

This was tested un a Ubuntu system. Testing is ongoing and I'll update this PR from a draft to a full PR when testing is done.

Issue(s) addressed

Fixes #1229
Note the container update will be made in a separate PR.

Checklist

• This PR addresses one issue/problem/enhancement, or has a very good reason for not doing so.
• These changes have been tested on the affected systems and applications.
• All dependency PRs/issues have been resolved and this PR can be merged.

[climbfuji]

This looks ok to me. Just want to confirm that the python variant in the unified environment stays off for now (because of version conflicts that we've been getting on several systems).

[eap]

@climbfuji - Yes I confirmed in my build that the python variant is not built unless I manually edit the spack yaml before running concretize and install. That means that even after this change, fortranformat will be unavailble on any platform using our unified-dev environment.

How are we going to service users dependent on this package? Are there platforms where we build the +python variant neptune environment? Alternatively, should we be putting this into a different meta package?

Adding @huishao-r for her thoughts on this ↑

[climbfuji]

@climbfuji - Yes I confirmed in my build that the python variant is not built unless I manually edit the spack yaml before running concretize and install. That means that even after this change, fortranformat will be unavailble on any platform using our unified-dev environment.

How are we going to service users dependent on this package? Are there platforms where we build the +python varient neptune environment? Alternatively, should we be putting this into a different meta package?

Adding @huishao-r for her thoughts on this ↑

We can't build the Python variant of neptune-env as is in the unified environment for two reasons:

1. py-xnrl is a code with restricted access; the code lives in the NRL enterprise github
2. Also, some of the dependencies of py-xnrl listed explicitly in the variant caused version conflicts in the past with the other complex python environments from JEDI and the UFS

We build neptune-env+python as part of the neptune-dev (NEPTUNE standalone) template on Navy machines (Narwhal, Nautilus, Atlantis, Sandy) regularly. Can't build anywhere else because of the xnrl business mentioned above.

Suggested way forward: split the python variant in neptune-env into two parts, one with basic utilities (incl. the new fortranformat) that concretize fine within the unified environment, and one with the more complicated utilities incl xnrl. If this sounds like a good idea, I will take care of it.

[eap]

@climbfuji I agree with the approach you mentioned, also that explains why I have variant/version duplicates in my concretize.

[email protected]
[email protected]
[email protected]%[email protected]+excel~performance
[email protected]%[email protected]+excel+performance
[email protected]
[email protected]
``

[climbfuji]

Let's merge this then and let me work on a follow-up PR.