At this point concretize.lp is sufficiently simple, and #27987 (comment) proposes a schema structure. So @tgamblin @becker33 if that seems agreeable I can update the schema validation and tests.

This now

• Implements the schema discussed in Configure requirements for a package #27987 (comment) (currently there are examples placed in a test-cfgs/ directory which will be updated to unit tests
• Implements preferences for condition groups (for a set of specs in a one_of specification, the earlier ones are preferred)
  • I still don't fully understand some of the logic around minimization (e.g. why do most of the minimization criteria have a build_priority - what is that?)

@becker33 this appears to be passing unit tests and I have mostly addressed #27987 (review) minus a couple issues I have questions about:

• I added preference weighting for conditions in condition groups, but wasn't sure about some of the mechanisms used to control/influence that like build_priority
• There was a request that member_id and stanza_id (now condition_group_id) be consolidated in Configure requirements for a package #27987 (comment) but I didn't think that was possible (which I explained in my response to that comment)

This still needs tests, but I wanted to make sure we agreed on the schema (now added with examples) and overall implementation first.

@scheibelp:

I still don't fully understand some of the logic around minimization (e.g. why do most of the minimization criteria have a build_priority - what is that?)

See the explanation here: abda8a4

If reuse is enabled, build_priority is set to some number greater than the number of optimization criteria, and it gets added to the priority of each criterion for packages that will be built. So if a package is to be built, we prioritize its defaults higher than minimizing the total number of builds. If a package is being reused and it satisfies any other imposed constraints, we prefer to take it as-is than to force its variants, versions, etc. to be the preferred/default ones.

For some intuition: if you don’t do this, and instead make minimizing total builds the absolute top priority, then if you have to build, say, CMake, then the solver will disable variants on the new CMake to reduce the total dependencies. E.g. it’ll give you a CMake without openssl and with other optional but still default features disabled. This is different than what a typical spack install cmake would do. build_priority ensures that new builds act more like typical spack installs when reuse is enabled.

@alalazo I added scheibelp#21 here, added a test which reproduces #27987 (comment), and fixed it in 1d733af

That commit however breaks reuse tests that check that you can reuse a package installation when the underlying package.py is changed (e.g. test_reuse_installed_packages_when_package_def_changes), so I'd need to investigate this more tomorrow/Monday.

I don't think 1d733af makes sense (or at least, it doesn't seem like it should be necessary to enforce the constraints we want). The test should still be useful (I'll be using it to debug the issue with "one_of").

I don't think 1d733af makes sense (or at least, it doesn't seem like it should be necessary to enforce the constraints we want).

I agree. Concrete specs derive the impose(Hash) from the hash(Package, Hash) atom, which is a choice of clingo to pop into existence if possible. Abstract specs instead derive impose(ID) from the fact that condition_holds(ID), without any choice involved. I think we just need to reconstruct some intermediate atoms which are not in the answer set for concrete specs.

These modifications should fix the unit-tests and take care of #27987 (comment) : scheibelp#23

I'm afraid one_of/any_of can be somewhat confusing. Maybe what's missing is some docs on how to combine one_of/any_of with unconditional requirements, like always use @4:.

Close/reopen to restart docs build

We should do a follow-on doc PR to address @haampie's concerns, but this LGTM.