I'm trying to get Volto to run inside a docker development environment when I use cookiecutter to create a site I run into problems:
f you try to do this inside docker you get a permission problem with node because it refuses to run properly when used as root or you get a docker-in-docker problem when you try to execute cookiecutter as user plone (even though you tried to allow docker for that user first). It feels like that's two issues though;
You will need to provide more information. Please include the error stack or messages, environment, and you know, the usual information that allows someone else to understand what you did.
The alternatives are (1) all maintainers of every Plone package or application must maintain their own code quality checks, or (2) have none at all. (1) leads to inconsistent quality checks across packages and versions, whereas (2) is just asking for trouble.
With a standardize repository for Plone at GitHub - plone/code-quality: Docker image to run code-quality checks, we have an option to follow consistent, current, updated, best practices in Plone software development. It can also be a base of a customized image for additional code quality checks.
I think @gogobd made a valid point. First it is not that uncommon that people do not develop on their own machine, but on a VM or in a container.
This is btw. officially supported by VSCode too:
It is a not-so-rare use case for several reasons: Company policies, Windows, locked down OS, or just to have a central place to develop on when switching between home office and office.
We need a solution here, just saying we do not support this is wrong for several reasons, but mostly because we want to be inclusive for all types of developers.
We do not need code-quality checks in a container. This is by design a problem. We try to reduce complexity by adding complexity.
Solution: We can put all this in a python package with dependency versions locked to a sane range, configuration provided there and run it with pipx. code-quality already is Python, so what stops us?
It is that simple simple, works everywhere and is mainstream as pip is (pipx if a package by PyPA).