If there is a desire to optionally offer the old behavior, we could

• Keep this variant
• Useconfig_args.append("--enable-prte-prefix-by-default") For +orterunprefix (not essential, but explicit)
• Use --disable-... (if available) fort ~orterunprefix

I get the impression though that no one was depending on ~orterunprefix, since it sounds like we would have been effectively ignoring that for @5:.

It would be nice (but not strictly required) to edit logic that looks at +orterunprefix, like

        if spec.satisfies("@1.3:"):
            if spec.satisfies("+orterunprefix"):

(even if you don't change that, the code will still work, but it would be easier to read if for example the range were updated to @1.3:4)

It sounds like you were going to make additional changes based on #43961 (comment), so let me know when that's ready and I can take another look.

Thanks for the feedback @scheibelp! I'll be looping back to this next week and will try to take some of this into account. I agree that for completion we should maybe offer the older behavior in 5.x versions (the ability to do ~, not currently present), even if the default behavior is changing (to +).

You're right that I'd still like to make some changes wrt the romio variant, but am having some trouble. I'll copy here a note that I had put in Slack, and I'd appreciate your expert guidance:

As written now,

variant("romio", default=True, when="@:5", description="Enable ROMIO support")
variant("romio", default=False, when="@5:", description="Enable ROMIO support")

, it's always false. I tried adjusting this to have the True case be @:4 instead [from our discussion above], but then I realized this is the overriding variants situation described in the docs and it continues to (correctly) be False regardless of version.
To switch the +/~ behavior of a variant based on version, does it need to be separately handled or can that be done entirely as variant definitions?

Thanks for the pointer, and yeah apologies it looks like we don't provide a way to do this with variant declarations. The only way I can think to do this right now is to add some config to etc/spack/defaults/packages.yaml:

packages:
  openmpi:
    prefer:
    - spec: ~romio
      when: @5:

(I'll check internally and get back to you on whether we'd want that sort of change, since we try to keep that scope as concise as possible)

I swear we were talking about adding a prefer directive (so we could encode this in the package itself), but that's not available right now. @alalazo was that you who mentioned this?

Yes. My take is that we don't want to have prefer directive in package.py, since packages might conflict with each other (and there's no opt-out to a directive). requires is different, cause it's really enforcing something.

Having prefer in packages.yaml is instead fine, cause that is "by user" and not "by package".

My take is that we don't want to have prefer directive in package.py

Fine by me, but I'm not following your reasoning

since packages might conflict with each other (and there's no opt-out to a directive

I assume conflicting preferences would have a winner (in terms of weighting) and because the user encoded them as a preference, they'd be fine with any particular one being ignored.

@tgamblin, who I spoke with, is working on a mechanism to adjust the default variant value based on when specs (so that will be a preferred mechanism to support this, vs. adding preferences to the default packages.yaml)

See #44425