Skip to content

add a pip locking versions functionality for backend addon installation #291

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ionlizarazu wants to merge 1 commit into
base: main
Choose a base branch
from
Open

add a pip locking versions functionality for backend addon installation #291

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion templates/add-ons/backend/{{ cookiecutter.__folder_name }}/Makefile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,6 +34,7 @@ endif
VENV_FOLDER=$(BACKEND_FOLDER)/.venv
export VIRTUAL_ENV=$(VENV_FOLDER)
BIN_FOLDER=$(VENV_FOLDER)/bin
LOCKFILE=pip-lock.txt

# Environment variables to be exported
export PYTHONWARNINGS := ignore
Expand Down Expand Up @@ -75,7 +76,8 @@ config: instance/etc/zope.ini

.PHONY: install
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

@davisagli davisagli Oct 9, 2025

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

@ionlizarazu ionlizarazu Oct 9, 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?

Copy link
Member

@davisagli davisagli Oct 9, 2025

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 •
edited
Loading

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

@davisagli davisagli Oct 10, 2025

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.


.PHONY: clean
clean: ## Clean installation and instance (data left intact)
Expand Down
Loading