We should not be setting these in the evaluation environments unconditionally, since that would allow packages to use the extras and dependency_groups marker variables in regular dependency declarations (outside of the context of a lockfile).

This would make it ~impossible for downstream tools to implement the following behaviour from PEP 751's specification update:

Outside of the context of lock files, these two variables should result in an error like all other unknown variables.

It would be good to add an explicit test for the unknown variable error case that this pertains to.

Outside of the context of lock files, these two variables should result in an error like all other unknown variables.

But other unknown markers are thrown as InvalidMarker errors during the parse phase. Should we, and can we keep consistent for extras? That may require a different version of parsing function, possibly with a flag

I made it a "should" statement for a reason. We could add a flag to evaluate() to specify the context and also clean things up for extra while we are at it, otherwise there's precedent of this code being sloppy/permissive in what it accepts.

@brettcannon thanks for the clarification, not sure if I interpret your feedback correctly

What I was thinking was instead of a for_lock argument, we have a context argument. That would take an enum that specified under what context the marker was being evaluated. We could have metadata which matches what it does now where extra is always set (and would be the default). We could have lock_file which doesn't have extra but has extras and dependency_groups always set. And then we could have requirement which has none of extra, extras, or dependency_groups automatically set.

FYI I'm not attached to any of these names.

@pradyunsg does the approach Frost took work for you (it does for me)?