I think the intended behavior here is that only torch==2.5.1 is installed, right?

If I look at the lock file, I see this for torchmetrics:

[[package]]
name = "torchmetrics"
version = "1.6.1"
source = { registry = "https://pypi.org/simple" }
dependencies = [
    { name = "lightning-utilities" },
    { name = "numpy" },
    { name = "packaging" },
    { name = "torch", version = "2.2.1", source = { registry = "https://pypi.org/simple" } },
    { name = "torch", version = "2.5.1", source = { registry = "https://pypi.org/simple" }, marker = "extra == 'extra-4-test-chgnet' or extra != 'extra-4-test-m3gnet'" },
]

Notice that both 2.2.1 and 2.5.1 will be used when there are no extras enabled (or even just when chgnet is enabled). Other dependencies on torch in the lock file look like this:

dependencies = [
    { name = "torch", version = "2.2.1", source = { registry = "https://pypi.org/simple" }, marker = "extra == 'extra-4-test-m3gnet'" },
    { name = "torch", version = "2.5.1", source = { registry = "https://pypi.org/simple" }, marker = "extra == 'extra-4-test-chgnet' or extra != 'extra-4-test-m3gnet'" },
]

Which is correct. Those markers are disjoint.

So I think this is a bug in resolution or possibly conflict marker simplification. This requires more investigation.

Thanks for the quick response!

I think the intended behavior here is that only torch==2.5.1 is installed, right?

Yes, that was my expectation.

This isn't directly related to the bug, but can I also ask a related question: is there a convenient way of specifying conflicting sets of extras?

I know conflict groups are possible, but in this case, I'd like to be able to m3gnet and alignn both conflict with chgnet and potentially others, while still being install each individually as an extra.

Is it currently necessary to specify each conflicting pair?

Your sets of conflicts can be of arbitrary length. If I'm understanding you correctly, then I think you just want this:

conflicts = [
    [
      { extra = "chgnet" },
      { extra = "alignn" },
      { extra = "m3gnet" },
    ],
]

And that will make all of them conflict with one another.

Your sets of conflicts can be of arbitrary length. If I'm understanding you correctly, then I think you just want this:

conflicts = [
[
{ extra = "chgnet" },
{ extra = "alignn" },
{ extra = "m3gnet" },
],
]
And that will make all of them conflict with one another.

Sorry, no I wasn't quite clear enough. For the above three, I would like to say that chgnet conflicts with both alignn and m3gnet, but alignn and m3gnet do not conflict with each other (we may want to install both).

More generally, I would like one set of non-conflicting extras that are all able to use something like torch==2.5.1, and another non-conflicting set which still require torch==2.2.1, while retaining the ability to install each individually.

Yeah you have to explicitly specify the conflicts. Like this:

conflicts = [
    [
      { extra = "chgnet" },
      { extra = "alignn" },
    ],
    [
      { extra = "chgnet" },
      { extra = "m3gnet" },
    ],
]

Yeah you have to explicitly specify the conflicts. Like this:

conflicts = [
[
{ extra = "chgnet" },
{ extra = "alignn" },
],
[
{ extra = "chgnet" },
{ extra = "m3gnet" },
],
]

Ok yep, thanks for clarifying! The number of pairs grows quite quickly as the two sets grow, but it's also quite a niche problem.

Yeah if you want to open a new issue with a more complete view of what you're trying to do, and also what your full pyproject.toml looks like with all the conflicts, then I think that would let us consider the UX here a bit more holistically. There is definitely somewhat of an assumption that the number of conflicts is overall small, and I think that influenced the current UX. Your specific issue might be niche, but it might be common enough to consider improving the UX. I'm honestly not sure.

One thing to consider here is that every conflict you define leads to a fork in the resolver. So like, if you have a crazy number of conflicts, there is definitely a potential there for slower resolutions.