Refactor monorepo #287
Refactor monorepo #287
Conversation
| clean: ## Clean installation and instance | ||
| @echo "$(RED)==> Cleaning environment and build$(RESET)" | ||
| @rm -rf $(VENV_FOLDER) pyvenv.cfg .installed.cfg instance/etc .venv .pytest_cache .ruff_cache constraints* requirements* | ||
| @rm -rf $(VENV_FOLDER) pyvenv.cfg .installed.cfg instance .venv .pytest_cache .ruff_cache constraints* requirements* |
There was a problem hiding this comment.
Please make sure this still doesn't delete the site data.
| description="Uninstall {{ cookiecutter.title }} setup." | ||
| provides="Products.GenericSetup.interfaces.EXTENSION" | ||
| directory="profiles/uninstall" | ||
| /> |
There was a problem hiding this comment.
How many times do we actually use the Uninstall profile on a project package? This package is meant to be very specific and configure Plone for a one usage.
This is the same scenario of a distribution where when you create a site based on that, you are all in.
For an add-on it is a very different game, as I want to be able to install / remove it over the lifetime of a portal.
There was a problem hiding this comment.
@ericof I understand the distinction between a project and an add-on. But this is the template I would use if I want to create an add-on with both backend and frontend, right?
There was a problem hiding this comment.
No. This template will focus only on the project monorepo.
I plan to have two other monorepo variants:
- Add-on
- Distribution
There was a problem hiding this comment.
@ericof Okay, but then let's please not remove things that are relevant to the other use cases until we have a replacement.
There was a problem hiding this comment.
(I know this is still a draft for now, so no actual problem to fix.)
| "Dockerfile", | ||
| "instance.yaml", | ||
| "Makefile", | ||
| "mx.ini", |
There was a problem hiding this comment.
We still need a solution for installing editable packages from git clones.
There was a problem hiding this comment.
We do need one, but I've been using editable checkouts pointing to a local directory with very good results. Of course, this is not a solution for the complete development cycle but it is what we have for today with uv.
plone-exportimport = { path = "../../../Plone/Core/plone.exportimport", editable = true }There was a problem hiding this comment.
@ericof The goal is that you can check out a repository, run make install, and have any necessary editable dependencies installed. Probably this means a Makefile command which does the cloning prior to running uv sync. And we need to document it.
There was a problem hiding this comment.
@ionlizarazu and me have been testing producing pip lock files (see #291) and we have also tested to produce uv lock files.
To do so, we have to set the project to be managed (setting [tool.uv] managed= true in pyproject.toml) and we have to remove the main-package = -e .[test] configuration in mx.ini.
After doing that, the rest of the mx.ini file keeps working, and uv installs whatever we set in this file as an editable install.
I need more testing on this, but I would say that we can go with both uv lock files and mx.ini.
| @@ -0,0 +1 @@ | |||
| Refactor monorepo project to use uv and repoplone. @ericof | |||
There was a problem hiding this comment.
We should also mention the refactor of the CI pipeline
There was a problem hiding this comment.
This is still a day or two from being done, but I will make sure to add the changelog entries for the CI and for the base Docker images
|
Perhaps I am a bit late to the party, but can we split the PR, one step introducing the repoplone, and another step introducing the uv lock files? I think it is easier to explain to the wider community and users of this tool if we go step by step and if we do not do an big overhaul of the tool in a very short time. |
|
I'm leaning into refactoring this PR into a new template (monorepo-ex) with all things introduced here and leave the existing monorepo template as it is. After all, what is being implemented here is already being used in production for the last few months. Opinions @erral, @davisagli? |
davisagli
left a comment
davisagli
left a comment
There was a problem hiding this comment.
@ericof Things I like here:
- moving the ansible stuff to a separate template
- updating the GHA workflows to use the shared workflows from plone/meta
I am not yet convinced we should switch to managing all Python dependencies using pyproject.toml and uv sync. Yes, we've been using that for some projects over the past few months and we've managed to make it work. But so far I don't see that it has any big benefit. Before, we needed an extra tool (mxdev) to create a final set of constraints and clone packages from git. After, we still need an extra tool (repoplone) to update the constraints in pyproject.toml, and we still need a solution outside of uv to clone packages from git.
Actually I don't see here where you are doing anything here to use the correct set of constraints for the selected Plone version.
Without a clear motivation to switch, I would rather keep the current solution. There is a cost to switching, because we have to educate the community about the new way, and create documentation which explains both the old and new way.
Let's talk about it. Maybe there are some important benefits to the change which I am forgetting at the moment.
|
ATM the management of the constraints is done via repoplone and the main goal is to advance us in the path of adopting distributions -- like kitconcept.intranet and Portal Brasil. There are other ways of handling lockfiles, but as uv seems to be the one with more traction, I decided to follow that path. I'm going to use this branch on my training, add a gigantic warning this is experimental, and document as much as I can. |
We should take a look at the pylock.toml format that was accepted as a PEP in March (https://peps.python.org/pep-0751/) and is already supported by uv.
Sure, I have no problem with that. I just don't want to rush updating the template on main. (I would already be okay with separate PRs to make the separate ansible subtemplate and switch to using the shared GHA workflows, though.) |
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 #