chore: ignore root uv.lock#136
Conversation
bdpy does not track the uv lockfile (CI resolves from pyproject.toml via pip), so ignore the locally generated uv.lock to keep `git status` clean and avoid accidental commits. Anchor the pattern with a leading slash so it only matches the repo-root lockfile, not any nested uv.lock.
There was a problem hiding this comment.
Copilot wasn't able to review any files in this pull request.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
ganow
left a comment
ganow
left a comment
There was a problem hiding this comment.
Thank you for creating this PR! This PR is great, and it is consistent with the current operation of bdpy.
To be honest, I am still somewhat unsure whether uv.lock should be tracked in Git. Initially, I decided not to include it intentionally, based on my understanding that bdpy is a package intended to be installed via pip. However, I later learned that the official uv documentation generally recommends checking uv.lock into version control, because it records the exact resolved versions installed in the project environment and enables consistent, reproducible installations across machines.1 Since uv’s project model also explicitly includes library projects intended to be built and distributed, for example by uploading them to PyPI,2 I understand this recommendation as applying, at least in principle, to PyPI-distributed packages as well.
At the same time, I think there is still some rationale for the current operation. Users who install bdpy via ordinary pip install will not necessarily use the exact dependency versions recorded in our repository’s uv.lock. Therefore, it is possible that a bug is reproducible in a user’s environment but not reproducible in the development environment managed by uv. There is also a related discussion in the uv issue tracker where the traditional distinction between applications and libraries is raised: application projects should include a lock file, while library projects may not need to.3 This is not uv’s official recommendation, but it reflects a concern that is relevant to this case.
My current view is that, as long as we use uv to manage the development environment, some environment differences from users who use bdpy without uv are ultimately unavoidable. That said, since we do not yet fully understand which combinations of third-party dependency versions may cause breakage in bdpy (and fully understanding this may not be realistic), I think there is still a reasonable basis for continuing the current policy of not including a strict lock file in the Git repository for now.
We may change this decision in the future and include uv.lock in the repository, but if that happens, we can simply update .gitignore again. So I would like to merge this PR as it is.
Footnotes
-
uv documentation, “Working on projects”:
uv.lockcontains the exact resolved versions installed in the project environment and “should be checked into version control.” See: https://docs.astral.sh/uv/guides/projects/#uvlock ↩ -
uv documentation, “Creating projects”: libraries are intended to be built and distributed, for example by uploading them to PyPI. See: https://docs.astral.sh/uv/concepts/projects/init/#libraries ↩
-
astral-sh/uv issue #10730: the issue author raises the application/library distinction for lock files. This is a discussion, not the official uv recommendation. See: https://github.com/astral-sh/uv/issues/10730 ↩
Summary
Ignore the root
uv.lockfile generated by local uv workflows.BdPy currently does not use
uv.lockas a source of truth: CI installs dependencies frompyproject.tomlusing pip, so a locally generated lockfile should not be accidentally committed.If the project decides to follow uv's recommendation and track
uv.lock, I will withdraw this PR.