# PEP 751: lock files (again)

**URL:** <https://discuss.python.org/t/pep-751-lock-files-again/59173>\
**Category:** Standards\
**Created:** [July 25, 2024, 6:51pm UTC](https://discuss.python.org/t/pep-751-lock-files-again/59173 "2024-07-25T18:51:17Z")\
**Posts on this page:** 1\
**Showing post:** 259

<div class="post-metadata">

**Author:** ![ncoghlan](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ncoghlan/32/14266_2.png) [@ncoghlan](https://discuss.python.org/u/ncoghlan)\
**Post date:** [September 14, 2024, 12:26am UTC](https://discuss.python.org/t/pep-751-lock-files-again/59173/259 "2024-09-14T00:26:59Z")

</div>

> [@charliermarsh](#):
>
> As long as we (uv) want to support this, I think we need to track markers on edges, not nodes. (I don’t have a strong objection to including them on the nodes, but we wouldn’t use those markers for anything.)

> [@brettcannon](#):
>
> So in this instance you could have a group representing each of your possible entry points into the lock file and still rely on the markers being accurate per-package. Or am I misunderstanding the concern

The issue noted here could also come up via groups: there may be parts of the combined marker that only apply if a particular group is installed, or a particular install root is requested.

Which means we may want to revisit the idea of adding a marker syntax for groups (in this PEP, not the groups PEP, since the base PEP doesn’t have a use case for it). Then the path dependent parts of the specifier could be qualified with things like `group = "dev"` (and roots could get synthetic group names like `group = "via-root-A"`).

---

_[View the full topic](https://discuss.python.org/t/pep-751-lock-files-again/59173)._