WARNING: THIS SITE IS A MIRROR OF GITHUB.COM / IT CANNOT LOGIN OR REGISTER ACCOUNTS / THE CONTENTS ARE PROVIDED AS-IS / THIS SITE ASSUMES NO RESPONSIBILITY FOR ANY DISPLAYED CONTENT OR LINKS / IF YOU FOUND SOMETHING MAY NOT GOOD FOR EVERYONE, CONTACT ADMIN AT ilovescratch@foxmail.com
Skip to content

Conversation

@ionlizarazu
Copy link

  • I signed and returned the Plone Contributor Agreement, and received and accepted an invitation to join a team in the Plone GitHub organization.
  • I verified there aren't any other open pull requests for the same change.
  • I followed the guidelines in Contributing to Plone.
  • I successfully ran code quality checks on my changes locally.
  • I successfully ran tests on my changes locally.
  • If needed, I added new tests for my changes.
  • If needed, I added documentation for my changes.
  • I included a change log entry in my commits.

If your pull request closes an open issue, include the exact text below, immediately followed by the issue number. When your pull request gets merged, then that issue will close automatically.

Closes #

@ionlizarazu ionlizarazu requested a review from ericof as a code owner October 9, 2025 11:00
@ionlizarazu ionlizarazu requested a review from erral October 9, 2025 11:01
install: $(VENV_FOLDER) config ## Install Plone and dependencies

@uv pip compile pyproject.toml requirements-mxdev.txt -o ${LOCKFILE}
@uv pip install -r $(LOCKFILE)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't look like the right way to use a lock file to me:

  • This Makefile target depends on $(VENV_FOLDER) which already installed packages without a lock file.
  • Compiling the lock file at the same time that you install it defeats the purpose of using a lockfile (to avoid unexpected updates)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reading the uv docs "When using an output file, uv will consider the versions pinned in an existing output file. If a dependency is pinned it will not be upgraded on a subsequent compile run."

So, this should lock the versions installed during the first run, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I retract my second point then. But it still doesn't make sense to compile the lockfile after packages were already installed into the virtualenv. And also @ericof is working on a larger change to use uv sync and uv.lock in #287

Copy link
Member

@erral erral Oct 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reading the uv docs "When using an output file, uv will consider the versions pinned in an existing output file. If a dependency is pinned it will not be upgraded on a subsequent compile run."

So, this should lock the versions installed during the first run, right?

we are not using UV lock files, but pip lock files, anyway as far as we checked the docs, the behavior of the command is the same, the file is checked before writing to it.

Anyway we need that support also inside the Dockerfile, to build the image with the locked versions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please talk to @ericof first and agree whether or not we can move toward using uv sync, so we don't have work happening in two different directions.

@erral erral mentioned this pull request Oct 10, 2025
8 tasks
@acsr acsr changed the title add a pip locking versions functionality for backend addon instalation add a pip locking versions functionality for backend addon installation Nov 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants